zopen-versions lists the version of z/OS tools and corresponding tools in 'brew'

[MikeFultonDev]

zopen-versions looks in your installed tools on z/OS and determines the version of the tool (if it's available) and then prints out the version of the tool in brew.
This is meant to help us with a few things:

• updating our packages to implement the zopen_get_version function in buildenv for each tool (uncomment the 'echo' for no version to see these files)
• determining if we are 'down-level' on the version of package we have

You can run this tool on tools installed locally (it defaults to search $HOME/zopen/prod). Ideally this could be incorporated into our CI/CD pipeline once we get all the gaps closed to ensure the gaps stay closed.

On my particular system with just a handful of packages installed in prod I see:

git zos-version 2.41.0 brew-version 2.41.0
less zos-version 632 brew-version 633
libiconv zos-version 1.17 brew-version 1.17
libpipeline zos-version 1.5.6 brew-version 1.5.7
libtool zos-version 2.4 brew-version 2.4.7
man-db zos-version 2.11.2 brew-version 2.11.2
ncurses zos-version 6.3 brew-version 6.4

So you can see we are down-level on 'less', libpipeline, libtool (maybe?), and ncurses for the handful of packages I have installed right now.

[IgorTodorovskiIBM]

It would be cool if we can get this automated into the docs similar to the Progress page: https://github.com/ZOSOpenTools/meta/blob/main/docs/Progress.md

And perhaps call out the ports that don't spew out a version. Alternatively, we could parse out the version from the pax: https://github.com/ZOSOpenTools/gitport/releases/download/Releaseline_gitport_1033/git-2.41.0.20230601_145058.zos.pax.Z
or
https://github.com/ZOSOpenTools/findutilsport/releases/download/Releaseline_findutilsport_947/findutils-4.9.0.20230423_232737.zos.pax.Z

[v1gnesh]

Hey Mike,
Funny story... when working on upstreaming some changes to a dependency of Terraform, I found a tool yesterday that can help keep the package version strings up-to-date as there are newer upstream releases.
It can work in CI as well, so automatically keeping things fresh is possible.
I haven't "double clicked" on it yet to understand how best to integrate that into our workflows/tools... added to the backlog.
Things could go a little faster if I had a faster machine 🙃

[MikeFultonDev]

I am imagining the tarball side is a bit more important for us and I haven't seen a good way to standardize this other than be cheating and piggy-backing on another package manager (in this case, brew)

[v1gnesh]

I'll see if I can nerd snipe the developer lol.
It's bare-bones in terms of dependencies, so builds ok on zOS.
If you both agree that this could be useful, @IgorTodorovskiIBM, could you please create a repo called bumpport :)
Thank you as always!

[IgorTodorovskiIBM]

I think we could still piggyback off of brew.
I expect if we use bump, we can create a custom Bumpfile such that it looks up the latest version from brew and updates the buildenv. For Git, we could look for the latest git tag.

[IgorTodorovskiIBM]

@v1gnesh , https://github.com/ZOSOpenTools/bumpport created. Thank you!

[v1gnesh]

It looks deceivingly simple, but is plenty capable.
The fetch filter for example can look for text in a web page and pick up version from there, using regex. I'm sure this will cover some unique cases.

Also, since GNU packages also have git links (savannah), is tar.gz being chosen for the ease of one-file download, or... ?
I understand tar.gz is common-place, just thinking about how far we can go with just git.

[MikeFultonDev]

See #322 for a snapshot of packages with a missing 'version'

[MikeFultonDev]

See #323 for a snapshot of which packages are out of date relative to brew.

[MikeFultonDev]

See #445 for issue