On 9/1/21 12:08 PM, ste...@eissing.org wrote:
> Having a look at the release scripts and how they work.
>
> I think we can use SVN and its branches/tags in a bit smarter way
> and make things easier. As Christophe mentioned, he would like a
> "--dry-run" option, because when things do not run smoothly to the
> end, you have not only a local messed-up state but the SVN repro
> itself is also changed without easy remedies.
>
> I propose to do all work up to release testing in separate,
> temporary branches that can simply be removed and restarted.
> This would not require a rewrite of the release scripts, but
> some re-ordering and branch name changes.
>
> - checkout branches/2.4.x
> - make sure change-entries are merged, commit
> - test branch locally for health
> - svn cp . branches/2.4.49-tmp
> - svn switch to branches/2.4.49-tmp
> - update versions, build docs, etc on that
> - commit this into branches/2.4.49-tmp
> - svn mv branches/2.4.49-tmp branches/2.4.49-candidate
> - svn switch to branches/2.4.49-candidate
> - create tar files and signature from -candidate
> - make them available for testing
> - announce release voting
> #
> # everything up to here can be reverted by "svn rm"
> #
> - switch to branches/2.4.x
> - bump versions in branches/2.4.x to 2.4.50
Sounds good. One addition on this flow: I would like to see the build docs
results finding their way back into the 2.4.x branch.
Probably by redoing build docs after switching back to branches 2.4 in the last
step.
Regards
Rüdiger
