{"thread":{"id":"61290","subject":"What are good reasons to use trunk-based dev, as opposed to release branch to release branch?","startedAt":"2024-04-07T17:16:53Z","lastAt":"2024-04-07T17:39:22Z","messageCount":2,"participants":["David Karr","rsbecker@nexbridge.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"492468","messageId":"CAA5t8Vp9ugXrgawDYA-+2mXT_RWPUUvv-rH9P+Exgb2dtvX6Sw@mail.gmail.com","threadId":"61290","inReplyTo":null,"subject":"What are good reasons to use trunk-based dev, as opposed to release branch to release branch?","fromName":"David Karr","fromEmail":"davidmichaelkarr@gmail.com","sentAt":"2024-04-07T17:16:42Z","receivedAt":"2024-04-07T17:16:53Z","isPatch":false,"sender":{"key":"davidmichaelkarr@gmail.com","avatar":null},"body":"Personally, I always use trunk-based development.  New changes go into\nfeature branches from master, and are merged to master after approval.\nWhen we're ready to make a release, we create the release branch from\nmaster, very few changes go into the release branch after we cut it.\nAny changes that have to go into the release branch are first merged\nto master, and then cherry-picked to the release branch.\n\nMy team maintains the \"platform\" for a large number of\nsimilarly-constructed microservices. That includes the build process,\nfoundation libraries, and some development guidance to the teams\ndeveloping those services. We advise using trunk-based development,\nbut it's up to each team what they actually do.  I recently heard of\nsome teams doing what I would roughly call \"release-to-release\"\ndevelopment, which means at some point in the distant past they\ncreated a release branch from master, and then the next release they\ncut from that release branch, ad infinitum.\n\nWhat bothers me is that although I know this practice is wrong, I\ndon't think I can fully and completely describe why it is wrong, and\nwhy TBE is better.\n\nAt a minimum, I know that with TBE, someone with no knowledge of the\nrepository can look at the master branch and know that represents the\nlatest work on the repository.\n\nI can't very argue that their practice results in \"merge hell\" when\nmerging to master, because they never actually do that.\n\nCan someone describe the flaws in this roughly named\n\"release-to-release\" strategy, and why TBE is better?\n"},{"id":"492469","messageId":"036201da8912$825b5050$8711f0f0$@nexbridge.com","threadId":"61290","inReplyTo":"CAA5t8Vp9ugXrgawDYA-+2mXT_RWPUUvv-rH9P+Exgb2dtvX6Sw@mail.gmail.com","subject":"RE: What are good reasons to use trunk-based dev, as opposed to release branch to release branch?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-04-07T17:39:09Z","receivedAt":"2024-04-07T17:39:22Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Sunday, April 7, 2024 1:17 PM, David Karr wrote:\n>Personally, I always use trunk-based development.  New changes go into feature\n>branches from master, and are merged to master after approval.\n>When we're ready to make a release, we create the release branch from master,\n>very few changes go into the release branch after we cut it.\n>Any changes that have to go into the release branch are first merged to master, and\n>then cherry-picked to the release branch.\n>\n>My team maintains the \"platform\" for a large number of similarly-constructed\n>microservices. That includes the build process, foundation libraries, and some\n>development guidance to the teams developing those services. We advise using\n>trunk-based development, but it's up to each team what they actually do.  I recently\n>heard of some teams doing what I would roughly call \"release-to-release\"\n>development, which means at some point in the distant past they created a release\n>branch from master, and then the next release they cut from that release branch,\n>ad infinitum.\n>\n>What bothers me is that although I know this practice is wrong, I don't think I can\n>fully and completely describe why it is wrong, and why TBE is better.\n>\n>At a minimum, I know that with TBE, someone with no knowledge of the repository\n>can look at the master branch and know that represents the latest work on the\n>repository.\n>\n>I can't very argue that their practice results in \"merge hell\" when merging to master,\n>because they never actually do that.\n>\n>Can someone describe the flaws in this roughly named \"release-to-release\"\n>strategy, and why TBE is better?\n\nThere are advantages and disadvantages to both. The key reason for release-to-release is to allow multiple releases to be simultaneously prepared with different features in each. TBE is fundamentally cumulative, with branches for new features and fixes. It supports development well but is not conducive to controlled production deployment. The TBE can be used at the same time as release-to-release. Developers work in TBE and should, IMO. But using merge-squash pull requests into release branches allows different ordering of features to be deployed in varying order (called sequencing). I would say, though, that continually basing release branches off of previous release branches is not a good practice as it does not allow any history cleanup - important when git is used as an release object repo. There should be a separate release main branch off which release branches are based. Fix release can be based off of their related base release branch, but main releases should not really be based off of other main releases. Periodic synchronizing of the TBE main with the release main can line things back up to reduce future conflicts.\n\nThe key take-away, perhaps, is that the two concepts are not mutually exclusive.\n\nJust my thoughts.\n--Randall\n\n"}]}