Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> There is stuff that belongs in releases but should not be present ever in develop branches at all, and vice-versa.

Divergence between development branches and release branches may be a sign of stuff that should be configuration-only/environment-configurable and outside of source control. "Build-once, run-everywhere" is a useful mantra: once a version has been cut, if it can be built once and only once and run in every development or release environment, you know that you are stably testing the same build artifacts in your QA environments that you will eventually release.

> Also, if you find a bug in a release candidate, you fix that bug alone. You do not add other changes just because someone committed them to the development branch.

If you are marking your released versions with git tags then you just build a short-lived branch from the release candidate tag, PR the fix to the short-lived branch (and any long term changes to the main/trunk branch), and cut the bug fix version from the short-lived branch (tag the new version). You don't need long-lived release branches to bug fix older versions and releases.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: