[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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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