Hacker News Reader

Comment by simiones | Hacker News Reader

Most people raised the problem of maintaining old releases beyond just hotfixes, which is valid.

Another problem my organization has hit with this approach is that, unless you somehow maintain 0 bugs level, you get to a point where you need to do 2 separate things: fix bugs on features that are already "done", while still developing new features, while integrating those in rapid succession. This is mostly true when preparing for a release while still having to work on features for future releases.

This can lead to the need to have two separate "main" branches, one that is used for stabilization, and another that is used for active development.

View on HN

To maintain old releases, I just cut a branch before I tag.

Merge to master, short-lived feature branches, and when it's release time, git checkout -b v1.5, git tag -a 1.5.0, and then cherry pick bugfixes onto that branch when it's time for 1.5.1. If you need more time to stabilize for 1.5.0, just add some time & development between cutting the branch and tagging it.

This is close enough to what we do -- and it works -- but since we support multiple releases at a time, it often ends up feeling like merging is pointless. Merging a dev branch into trunk feels good, but honestly most git interactions involve cherry-picking sets of commits to old releases, or to create hotfixes (So much, in fact, that we built some tooling around it to make it easier to not screw up). So then, you start to wonder, why am I special casing this one situation and using merge to trunk, and using cherry pick everywhere else.

I cherry pick (or rebase, usually) to master, too. I only merge when I'm actually merging divergent histories.

This is what we do as well and it works fine. We do data processing and have a mix of processing which needs to completed in near real time and other processing which we have a bit more leeway on the time.

The real time processing runs on stable releases which are tags created off of a stable branch (as you have suggested) and all the other processing runs off the tip of master.

Separate the deployment from the release. Use feature flags for feature development. Deploy unfinished features if you need to. Remove the feature flags once the feature has been released.

Reply on news.ycombinator.com