[Release Engineering] Reconsider how we organise our code and cut our releases #2022
vladbailescu
started this conversation in
General
Replies: 1 comment
-
We discussed inside the team that we want to cut release 2.18.0 from the
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Currently we've been relying on having two main branches
master
(which follows the changes from the latest releases and allows quick/hotfix releases) anddevelopment
(which serves as an integration branch for all features and fixes).Synchronising changes between the two branches is a pain as sometimes commits from
development
need to be cherry-picked manually tomaster
before we do a release and doing a merge afterwards will result in duplication of commits.We need a better way to manage this process and the alternatives so far are:
1. Use something similar to
gitflow
development
as the main branch used for integration of feature branches and fixes.master
as a hotfix branch that always tracks the latest release.development
, release from the release branch and merge back changes into bothmaster
anddevelopment
master
, release from the release branch and merge back changes to bothmaster
anddevelopment
2. Use trunk-based development
See https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development
main
main
, release from this branch and merge back changes intomain
main
Beta Was this translation helpful? Give feedback.
All reactions