3 ms·
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, gi
by ddevault 6y ago
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.
- cmurphycode 6y agoThis 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.
- ddevault 6y agoI cherry pick (or rebase, usually) to master, too. I only merge when I'm actually merging divergent histories.
- __turbobrew__ 6y agoThis 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.