Hi! The release procedure for Tomcat that we used up to recently is documented in the Wiki, https://wiki.apache.org/tomcat/ReleaseProcess
Do we change it now, when Git is used instead of Apache Subversion? I see the following issues: 1) When preparing a release, one does a tag in Subversion that differs from the main branch. Technically, with Git it means that one creates a new branch and a tag on that branch. I think, the process may be the following: a) create a "RC" branch locally, b) create a tag on that branch, c) push only a tag, not the branch to the remote repository. I have never done (c). I usually push a branch with a "with tags" flag, so both a branch and tags are pushed. Technically, it is possible to push branch with tags and delete the branch from the remote repository later. 2) Sometimes a release manager does re-tagging. It needs testing whether we have the rights to delete a tag, and how those deletions are replicated between repositories. I think the possible solution that simplifies the things will be (1) create the tag on the main branch, (2) publish (push) the tag only when the release artifacts have been uploaded, so that it is known that the number won't be reused for a different set of artifacts. The specific steps are the following: 1. Edit the following files on the main branch and commit: build.properties.default res/maven/mvn.properties.default webapps/docs/changelog.xml - remove "dev" suffix - verify that the version number is correct - remove "in development" frem the section title in changelog (The wiki page misses the "default" suffix from the first file name and does not mention the two other files. Usually the mvn.properties.default is updated after a release, so it already contains the correct version number.) 2. Push the commit, to ensure that it can be pushed successfully without conflicts and so that this commit is present in the main branch and is visible in the repository. At this point subsequent development for the next version of Tomcat is technically possible. The new commits won't conflict with the changed files. 3. Do a build. 4. Publish the files to Maven Staging repository 5. Publish the files to Dist.a.o svn repository. At this point the release artifacts are published, so no re-tagging is possible. 6. Create a tag in Git. 7. Push the tag. 8. Verify that the tag is visible in the repository 9. Send a [VOTE[ e-mail. 10. Update the following files for the next version of Tomcat build.properties.default res/maven/mvn.properties.default webapps/docs/changelog.xml - Increment the build number in mvn.properties.default - Increment the build number and add "-dev" suffix in build.properties.default - Mark the current version as "vote in progress" and a section for the new version in changelog.xml. 11. Commit and push. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
