I'm fine with your process as proposed. It'll be up to the release manager to communicate "pencils down" and "work resumes" notifications to the dev list, but I think that will be enough of a semaphore with this community.
+1 On Tue, May 3, 2022 at 5:57 PM Allen Wittenauer <a...@apache.org> wrote: > > Hi. > > Currently we cut a branch and do all the release work in that > branch. While that was done to prevent work stoppage in the main branch > while the release work is being done, it also has the side-effect that the > release tags never show up in the main branch, making tools like git > describe not work at all. Given that I can think of only once in the > history of the project where a commit went into main that didn’t end up in > a release while the release process was ongoing… > > * Given the low rate of participation, does that protection these > days, does that protection still make sense? > * What if the release process was changed such that all of the > release work is (effectively) done in main? > > In my head: > > - release version gets updated in maven.config, etc > - main is now effectively frozen for things that won’t end > up in the release > - release cycle: > - release gets cut from a given sha > a. if issues, PR -> main (and merge in any PRs > that are hanging around?), re-cut from latest sha > b. continue until approved > - release sha is rel/ tagged > - snapshot version gets updated in maven.config after tag > > > IMHO, there is tremendous value in having release tags being > marked in the main branch. At some point (esp w/YETUS-1161 committed), we > may very well be in a position to have the Apache Yetus version > autodetermined by the value of the git tag, streamlining the release > process even further. > > Thoughts?
