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
- Stefan
-------------------------------------------------------------------------
Summary of what the release process involves and what each script does:
0. tag.sh
svn checkout $HEAD of branch
check version numbers
check SVN tag for version does not exist
check PGP/GPG key in httpd-dist/KEYS
update Copyright in docs/manual/style/xsl/common.xsl
checkout docs-build, build docs, remove docs-build checkout
run "update-changes" using Makfile.in
Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h
svn commit all changes
Change local include/ap_release.h back
bump up patch version in CHANGES, STATUS, docs/manual/style/version.ent
before committing this, copy $HEAD of branch to tags/$version
svn commit the bump-up changes to branch
1a. release.sh
svn export $HEAD of branches/2.4.x
svn export of dependencies (APR)
apply patches (currently broken)
prepare CHANGES_<version>
invoke roll.sh
1b. roll.sh
run releasecheck.sh (checking libtool availability? for what?)
remove files not wanted in release (fixed list)
touch .y dependants (fixed list)
remove doc sources (*.xml *.xsl)
move srclib into -deps sibling directory
build tar balls
build checksum files (lots of alternatives if openssl is not found, do we need that?)
signing the files
substitute new version number in various files
2. voting
3. push.sh
checkout https://dist.apache.org/repos/dist/
remove old CHANGES_$major.minor
generate new CHANGES_$version, CHANGES_$major.minor
modify Announcement$major.minor
svn move generated tar, deps and CHANGES
svn commit
4. update bugzilla
5. announce.sh
lots of messing with dist and pmc to get security details in
some sanity checks
send mails
send more mails
svn commit changes to "$dist_base" "$branch_base" "$private_base" "$site_base"
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
- Stefan
-------------------------------------------------------------------------
Summary of what the release process involves and what each script does:
0. tag.sh
svn checkout $HEAD of branch
check version numbers
check SVN tag for version does not exist
check PGP/GPG key in httpd-dist/KEYS
update Copyright in docs/manual/style/xsl/common.xsl
checkout docs-build, build docs, remove docs-build checkout
run "update-changes" using Makfile.in
Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h
svn commit all changes
Change local include/ap_release.h back
bump up patch version in CHANGES, STATUS, docs/manual/style/version.ent
before committing this, copy $HEAD of branch to tags/$version
svn commit the bump-up changes to branch
1a. release.sh
svn export $HEAD of branches/2.4.x
svn export of dependencies (APR)
apply patches (currently broken)
prepare CHANGES_<version>
invoke roll.sh
1b. roll.sh
run releasecheck.sh (checking libtool availability? for what?)
remove files not wanted in release (fixed list)
touch .y dependants (fixed list)
remove doc sources (*.xml *.xsl)
move srclib into -deps sibling directory
build tar balls
build checksum files (lots of alternatives if openssl is not found, do we need that?)
signing the files
substitute new version number in various files
2. voting
3. push.sh
checkout https://dist.apache.org/repos/dist/
remove old CHANGES_$major.minor
generate new CHANGES_$version, CHANGES_$major.minor
modify Announcement$major.minor
svn move generated tar, deps and CHANGES
svn commit
4. update bugzilla
5. announce.sh
lots of messing with dist and pmc to get security details in
some sanity checks
send mails
send more mails
svn commit changes to "$dist_base" "$branch_base" "$private_base" "$site_base"