- Finally currently we have a bit of a potential race condition with the release process.
How do we ensure no commits are made, between (1) the moment the decision to make the current code base into a new release is made, and (2) the version is changed and committed into git, after which normal commit process can resume. Basically, some kind of code freeze must happen for the duration of the release, which ideally should be pretty quick. But I’m not sure how this no commits period can be enforced. And there could be problems with the pending release, so it might not be quick at all.
Alternatively, a release branch can be used, and any changes merged back into master upon successful release. The only thing I don’t understand about this method is the release tag, which seems to be wrong.
The release branch idea is (adopted from release-branches):
- create a release branch:
git checkout -b release-1.0.5 master
git commit -a -m "Bumped version number to 1.0.5"
- make release
This may involve some extra commits if something needs to be fixed.
package(s) are uploaded
- merge the release branch back into master and delete it
git checkout master
git merge --no-ff release-1.0.5
git tag -a 1.0.5
The very last command of the last part that doesn’t compute for me (
git tag -a 1.0.5 in the master branch). If master’s
HEAD has moved since
release-1.0.5 was made, the tag will include changes that weren’t part of the release, so if someone checks out tag
1.0.5 it won’t be the same as the files that were released in step #2.
For example, if we use the approach of
1.0.6.dev0 to be able to tell whether a user uses a released
1.0.5 or the git
HEAD version, we will never see
version==1.0.5 in the master, since when we merge back there will be