Tagging releases? Useful or not?

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?

In our particular case I just periodically rebase our fork on top of the release-name.master branch rather than focusing on the periodically tagged point versions. In terms of communicating important changes, perhaps just maintain a thread here in Discourse where notable changes are appended to the thread so that any interested parties can read through that thread to know what the current state is.

1 Like

@nedbat Since no feature are supposed to land on juniper.master I don’t think it really makes sense to have these juniper.x tags as long are we are well informed that security or bug fixes are being pushed to juniper.master. So we can update our internal fork and in the meanwhile regularly updating it any way.

I am in favor of dropping the minor branches but having a mailing list or a forum thread dedicated to the announce of important fixes being pushed on {juniper.master} could be really nice.

1 Like

We also don’t follow the juniper.X tags, we only look at the .master branch continuously. I’m in favor of removing those.

We’ve relied on the tagged named releases to help old instances through breaking database migrations, see Migrate from Eucalyptus to Juniper, but I believe that’s the only reason.

Interesting. If we hadn’t tagged .2, .3, etc, what would that page look like? The tags weren’t made with regard to migrations, so you would be jumping in larger increments? Without the tags, you wouldn’t have a name for the point to migrate to, other than “tip of Ironwood master”.

Maybe we should make a tag when the release is official, and then one more when the next release is ready? “Ironwood.last” and “Juniper.1” at the same time?

It’s totally possible that some steps can be skipped. I can only report the steps we know we went through successfully as part of our usual release update process.

The ficus.3 and ficus.4 tags were created to help with the django social and djcelery migration issues. So if we have anything similar to manage in future, tags are a nice way to do it. Otherwise, I think it’s fine to just use the master branches.

I don’t think that’s necessary either. Any changes made to ironwood.master since juniper.1 is cut are likely to be things like fixing breaking dependencies, and so the ironwood.last won’t really be very useful.

This is a good reason to make a tag, because we determine that it’s a needed intermediate stop in an upgrade path.