Our current release process works like this:
- About a month before the release, create the “open-release/release-name.master” branch from the master branch. Let’s call this the release-master branch.
- Testing and fixes happen on the release-master branch
- Once everything is working and stable, we tag the release-master branch with “open-release/release-name.1” to mark the official supported release.
- Fixes continue to accumulate on the release-master branch.
- Occasionally, at poorly-defined times, we tag the release-master branch again, with “open-release/release-name.2”, “open-release/release-name.3”, and so on.
I’m wondering whether that last step makes sense. We tagged “open-release/juniper.3” after an important security fix, but then immediately added more commits to the release-master branch for more fixes. So almost as soon as .3 existed, it was out of date.
Is there a reason to create the .2, .3, etc, tags? If we don’t create them should we still make the .1 tag? Is there a better way to communicate what’s happening on the release-master branch?