hpc
release the next version of IOR
I intended to feature freeze IOR-3.4 back in December to get one more stable release before we merge in the change to the way -z works. That didn't happen, so what should we do?
- Cut the IOR-3.4 branch from master as it was in December and just catch up. This will cause anyone who built IOR after December (e.g., IO-500) to have a spurious "ior-3.4+dev" version even though they're using features that won't appear in 3.4.0
- Feature freeze now and just increase the scope of IOR-3.4's changes.
Neither is great, because IOR-3.4 will be significantly different than IOR-3.3 and there will have been no stable interim releases. Maybe this is OK for most non-IO500 users. If we go down the path of option 2, should we consider renaming it IOR-4.0 or something?
I think IOR-4.0 is fine given the many major changes, particularly to the API.
I think, we should release the current version as Version 4.0. Can you do this Rob? I'm not much familiar with the release of new versions using the classic Gnu tools :-)
Cutting new releases has been on me, and I've been really bad. The actual release process is easy; the hard part is building up the changelog, and it only gets worse as I put it off.
My preference would be to cut a release candidate off the last IO500 tag since that version has been tested by a bunch of people, even if just with a limited set of options. If it weren't for the burden of updating the documentation and release notes, I can create the release candidate in just a few minutes.
How do people feel about letting the documentation part of the release suffer?
Add a GitHub issue for the docs you know are out of date and add that issue to the release notes?
On Fri, Feb 17, 2023, 11:53 Glenn K. Lockwood @.***> wrote:
Cutting new releases has been on me, and I've been really bad. The actual release process is easy; the hard part is building up the changelog, and it only gets worse as I put it off.
My preference would be to cut a release candidate off the last IO500 tag since that version has been tested by a bunch of people, even if just with a limited set of options. If it weren't for the burden of updating the documentation and release notes, I can create the release candidate in just a few minutes.
How do people feel about letting the documentation part of the release suffer?
— Reply to this email directly, view it on GitHub https://github.com/hpc/ior/issues/361#issuecomment-1435034376, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARMIENCIEXKJ2D3SFW5WCLWX63KTANCNFSM43KWEHUQ . You are receiving this because you commented.Message ID: @.***>
Let's base 4.0 off the last tagged IO500 release (06fc08e147600f4e5896a5b9b2bf8f1c4a79121f). Once #455 is merged I will make the 4.0 branch, cherry pick it in, and do a release candidate.
I'd also like to drop the NEWS file. Do people still use those things? Right now the autotools config will not allow a release without NEWS being up to date which is a little onerous.
Terrific Glenn. I do like a changelog file generally. Agreeably, there is not too much value given many small changes took place.
Could folks look at the release tarballs for https://github.com/hpc/ior/releases/tag/4.0.0rc1? Once we've kicked the tires, we can formally release 4.0.0.
Sadly, CI broke when travis-ci.org went away and we have two years of new code that hasn't been regularly tested. I also don't use weird features of IOR for work anymore, so I'm relying on the community to do the testing.
This is done: https://github.com/hpc/ior/releases/tag/4.0.0. Only took two and a half years. Yikes.