New release

[JulianKunkel]

It would be great if we manage to release a new version of IOR/MDTest before the IO-500 submissions for SC.

Maybe we could make a new release candidate version from the testing branch and then we promote it? Or should we just switch IO-500 to use the testing branch. As people will run it for the IO-500 we will get some testing done and then we can merge back testing into the IOR main branch? Other opinions?

[johnbent]

Let’s please not use our IO500 submitters as testers for IOR/mdtest.

We should use release candidates for IO500. Makes sense to have one ready in time for SC submissions. I’d save three months ahead would be perfect.

On Aug 10, 2018, at 12:19 PM, Julian Kunkel notifications@github.com wrote:

It would be great if we manage to release a new version of IOR/MDTest before the IO-500 submissions for SC.

Maybe we could make a new release candidate version from the testing branch and then we promote it? Or should we just switch IO-500 to use the testing branch. As people will run it for the IO-500 we will get some testing done and then we can merge back testing into the IOR main branch? Other opinions?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[glennklockwood]

A new release is very long overdue. My preference would be

0. update the version number in NEWS, META, and other files used by autoconf
1. merge testing back into master
2. create a "rc" (release candidate) branch from master
3. create a "3.2rc1" tag (or whatever version should be next) from the "rc" branch
4. reference this master -> rc -> 3.2rc1 in the io500 repository

This lets IO-500 users beat up this release candidate. If they discover bugs that need to be patched, the process would then be

1. pull patches directly to the "rc" branch
2. merge rc back back into master
3. create a new 3.2rc2 (or 3.2rc3, etc) tag from the "rc" branch
4. update io500 to reference the new 3.2rc2 tag

This allows us to continue feature development in master without dragging new (and potentially unstable) features into the 3.2 release or affect the IO-500 benchmark set.

What do you all think?

[glennklockwood]

Let’s please not use our IO500 submitters as testers for IOR/mdtest.

We should use release candidates for IO500. Makes sense to have one ready in time for SC submissions. I’d save three months ahead would be perfect.

I generally agree, but the new stonewalling stuff is only in testing right now. There's no way to do mdtest-stonewalling tests using an officially "stable" version of IOR/mdtest right now.

[JulianKunkel]

Glenn, I'm in favor of this. John, we have to do some testing of the new branch and there are plenty of changes now. Bugs will always be found when we add new features, important is to fix them quickly ^-^ Otherwise, we may opt for IO-500 to remain on an older release, if we wanted.

2018-08-10 19:27 GMT+01:00 Glenn K. Lockwood notifications@github.com:

A new release is very long overdue. My preference would be

1. update the version number in NEWS, META, and other files used by autoconf
2. merge testing back into master
3. create a "rc" (release candidate) branch from master
4. create a "3.2rc1" tag (or whatever version should be next) from the "rc" branch
5. reference this master -> rc -> 3.2rc1 in the io500 repository

This lets IO-500 users beat up this release candidate. If they discover bugs that need to be patched, the process would then be

1. pull patches directly to the "rc" branch
2. merge rc back back into master
3. create a new 3.2rc2 (or 3.2rc3, etc) tag from the "rc" branch
4. update io500 to reference the new 3.2rc2 tag

This allows us to continue feature development in master without dragging new (and potentially unstable) features into the 3.2 release or affect the IO-500 benchmark set.

What do you all think?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hpc/ior/issues/74#issuecomment-412167148, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1uytFZfSaAqrd_JjQUlV9tGNjcxIVcks5uPdCqgaJpZM4V4nfB .

-- Dr. Julian Kunkel Lecturer, Department of Computer Science +44 (0) 118 378 8218 http://www.cs.reading.ac.uk/ https://hps.vi4io.org/

[johnbent]

Glenn. I like this plan. Julian, it needs testing for sure. However, we shouldn’t use IO500 submitters as IOR testers. If that means that IO500 is on an older, stable branch, then that is how it should be in my opinion. We could certainly tell them that if they want the stonewall for example, then they are welcome to use a pre-release version.

On Aug 10, 2018, at 12:31 PM, Julian Kunkel notifications@github.com wrote:

Glenn, I'm in favor of this. John, we have to do some testing of the new branch and there are plenty of changes now. Bugs will always be found when we add new features, important is to fix them quickly ^-^ Otherwise, we may opt for IO-500 to remain on an older release, if we wanted.

2018-08-10 19:27 GMT+01:00 Glenn K. Lockwood notifications@github.com:

A new release is very long overdue. My preference would be

1. update the version number in NEWS, META, and other files used by autoconf
2. merge testing back into master
3. create a "rc" (release candidate) branch from master
4. create a "3.2rc1" tag (or whatever version should be next) from the "rc" branch
5. reference this master -> rc -> 3.2rc1 in the io500 repository

This lets IO-500 users beat up this release candidate. If they discover bugs that need to be patched, the process would then be

1. pull patches directly to the "rc" branch
2. merge rc back back into master
3. create a new 3.2rc2 (or 3.2rc3, etc) tag from the "rc" branch
4. update io500 to reference the new 3.2rc2 tag

This allows us to continue feature development in master without dragging new (and potentially unstable) features into the 3.2 release or affect the IO-500 benchmark set.

What do you all think?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hpc/ior/issues/74#issuecomment-412167148, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1uytFZfSaAqrd_JjQUlV9tGNjcxIVcks5uPdCqgaJpZM4V4nfB .

-- Dr. Julian Kunkel Lecturer, Department of Computer Science +44 (0) 118 378 8218 http://www.cs.reading.ac.uk/ https://hps.vi4io.org/ — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[glennklockwood]

OK. Well let us know when the ior/testing branch is ready to go back into master with a pull request. We can use that point as our feature freeze for IOR 3.2 and go ahead with creating the rc and 3.2rc1 tag. Happy to work with IO-500's schedule if it makes sense.

[JulianKunkel]

Imho it is good to go. Documentation needs minor update at some point ..

Glenn K. Lockwood notifications@github.com schrieb am Mo., 13. Aug. 2018, 18:45:

OK. Well let us know when the ior/testing branch is ready to go back into master with a pull request. We can use that point as our feature freeze for IOR 3.2 and go ahead with creating the rc and 3.2rc1 tag. Happy to work with IO-500's schedule if it makes sense.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hpc/ior/issues/74#issuecomment-412604006, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1uyhjkv644T4wPavM-6lYKoCnV5QoTks5uQbtTgaJpZM4V4nfB .

[glennklockwood]

OK, testing has been merged into master. The next step will be to merge master into a new rc branch to feature-freeze. I'm not sure how much testing should be done between now and cutting an rc, but feel free to make that call and we can

1. Update the versions in NEWS, META, and autoconf to 3.2 in the master branch
2. Create a new rc branch and merge master into it, then tag 3.2rc1
3. Enumerate all the changes that are going into 3.2 vs 3.1 for release documentation and contribution credits
4. ...
5. Profit (and do a formal 3.2 release)

[glennklockwood]

@roblatham00's recent testing and valgrinding have made me feel a little more comfortable about the stability of master after testing got merged back, so I created an rc branch. If more patches are contributed to master, we should cherry pick them into rc. Otherwise, consider today the start of the feature freeze for 3.2.

[glennklockwood]

We talked briefly about what's needed to do a 3.2.0 release at SC, but I forget exactly what patch we wanted to pull from master into rc before doing the release. @JulianKunkel, did you want to do something related to the backend-specific arguments?

[JulianKunkel]

Could you merge pull requests: #104, #105, #110 Now I reverted the change back to HDF5 in the banch here: https://github.com/hpc/ior/compare/feature-hdf5-backend But I kept the improved handling of the modules --module.option instead of the -- syntax that you disliked.

Am Di., 4. Dez. 2018 um 00:13 Uhr schrieb Glenn K. Lockwood < notifications@github.com>:

We talked briefly about what's needed to do a 3.2.0 release at SC, but I forget exactly what patch we wanted to pull from master into rc before doing the release. @JulianKunkel https://github.com/JulianKunkel, did you want to do something related to the backend-specific arguments?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hpc/ior/issues/74#issuecomment-443919973, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1uysMYxchvHPN9EBY9zMBVVLyaWpugks5u1b4ygaJpZM4V4nfB .

-- Dr. Julian Kunkel Lecturer, Department of Computer Science +44 (0) 118 378 8218 http://www.cs.reading.ac.uk/ https://hps.vi4io.org/

[glennklockwood]

104, #105, and #110 have all been merged into master, but no RC. We decided to only pull #104 into the 3.2 release, since #105 and #110 change the application behavior.

Because #104 was pulled forward, @roblatham00's collective metadata option for the HDF5 option was also pulled into RC since #104 depends on it. I reason this is OK because 7d2464f is well encapsulated and can be negated at build time.

With this, I think we're ready to release. I've tagged a release candidate for 3.2.0, and we can let that sit for a week before doing a final 3.2.0 release.

[glennklockwood]

I think 3.2.0 is ready to go after the last autoconf bugfix. I've got the artifacts built and will cut the release tomorrow (Wed, Dec 19). I will also branch a v3.2 off of rc, and from this point forward, hotfixes for the 3.2 release will be applied to that branch for releases 3.2.1, 3.2.2, etc and backported down to rc and master, if applicable.

Following that, I am going to merge master into rc, effectively feature freezing the next version, 3.3.0. I still owe everyone a few items that are tagged for 3.2.0 like a written proposal for our branching model. I will work on that in the new year.