Hi Alex, I'm with the article exposed in [1], I think I'm using it since 2010.
But I think we have a different interpretation of a release branch. For what I saw for almost 10 years using git is that we have: - master: Is the "stable" branch with "released" content. So latest release can be found at master - develop: Is what we use to develop incrementally. If we need to fix a bug or add an enhancement, we do here. develop must be always stable, so if a fix is just one commit, we can do this directly on develop, but if more work needs to be done, and more than one commit is needed to be stable again, then we need to create a feature branch. - feature: changes that need more than 1 commit to be stable. Do all commits in this kind of branch, and finally merge in develop when finished. Then this branch can be removed. - release: Here's where I see differences. Once we decided we want to release, is because develop has the final state to cut a release. No more commits are needed for that release. So once a RM start the process and creates release branch from develop, then no more things should go to release branch. NOW: If we have to fix something for release, this is done in release and then "merged" (not cherry-picked) to develop at any time. Finally as we get to the final process, release is merged in master and develop. - hotfix: we don't use it this for now. I think is normal since we are still doing very heavy development, but when we get to 1.0 I expect hot fixes will start to have relevance. IOW, I expect we'll get a time where releases will be lower since we'll have a very stable tech, so hot fixes will come to fix concrete bugs discovered in a release that need to be fixed, and users don't want to enter other kind of evolutions in the SDK. Notice that in parallel: develop can continue to evolve, but that will not go into that current release, will go to the next. As well, I think Cherry pick can be an option for many other use cases. Is like using rebase, those are very powerful tools to use when needed. Just we all need to know when is the right way to use it. I think the problem right now is that when we start the release, we continue with open mind to add all we do in develop. This is due to our current release process getting to long in time. I think next release process should be very less time and will be less new things in develop so what we have in release will be what we really release, instead of continue adding new develop things. [1] https://nvie.com/posts/a-successful-git-branching-model/ El sáb., 5 oct. 2019 a las 2:19, Alex Harui (<[email protected]>) escribió: > Hi, > > I think we may need to be more careful about branches and commits in the > future. I saw a fair number of merge conflicts for the RM to have to > resolve to merge the release branch back into develop. The use of > cherry-picking may be part of the problem. I wrote down my thoughts on the > subject in the wiki > https://github.com/apache/royale-asjs/wiki/Branch-Management > > Now it is true that in the future, the release branches may not live as > long so there will be fewer conflicts, but if we are successful and become > a more active community, we will want to have good practices around this so > that the develop branch can handle less stable commits while were getting a > release out. > > My takeaway is that cherry-picking is not a best practice > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html > because the changes in each branch are not correlated. > > Let's discuss, > -Alex > > -- Carlos Rovira http://about.me/carlosrovira
