Bug fixes in older branches or newer branches first

[jonahgraham]

Started in #863 (reply in thread) but split out to not distract from the original purpose of that discussion.

@Bananeweizen said:

Jonah, independent of the remaining discussion: That's why I require our (company) developers to start bug fixing on the oldest branch a bug exists on. Merging the older branch into the next newer one repeatedly is trivial (and even automated in some version control systems). Cherry-picking backwards from newer branches is an antipattern IMO.

That is interesting, and maybe in the context of #863 something that should be considered. In the "old days" when Eclipse often had two active branches (maintained release branch and master branch) new code generally had to go to the master branch first to be tested and once it was good it was then cherry-picked to older branch.

The flow of merging forward is indeed generally easier, but do you (@Bananeweizen) think that kind of model can work in Eclipse?

[laeubi]

From my experience it does not really matter, if its trivial in the one direction its trivial in the other as well. If there are conflicts (or even worse: move/rename/deletes) I also often just apply the path just a second time than trying to get it cherrypicked and fiddle around with conflicts.

So I also would vote for fix on master first, then decide if its worth to back-port what might be a simple cherry-pick or even just change the few lines such a bugfix(!) should include. If it is more work, this is generally a good indication to not backport the code but fix the bug in the next release.

[iloveeclipse]

Same here, git makes both forward/back propagation very easy. Surely, one can't expect an easy back propagation of a complete feature developed for a months, but propagation of trivial fixes is usually a no-brainer.

Btw, since we don't maintain branches in platform except JDT "beta" branch, not sure how this discussion relates to platform releng?

[jonahgraham]

Btw, since we don't maintain branches in platform except JDT "beta" branch, not sure how this discussion relates to platform releng?

Because that is what we are talking about in #863 :) - my understanding is you are proposing having two active branches for a few weeks.

[iloveeclipse]

OK, in this case I don't see any issues with either back or forward propagation, since we never had "big" changes in RC time. Usually this will be few smaller patches. Pushing them first on master and back propagation to "release" branch after I build confirmed no regression would be my personal preference workflow.

Same for final updates of 3rd party dependencies on "release" branch - they can be trivially propagated to master, it's usually few lines in some pom files.

[Bananeweizen]

Cherry-picking forward or backward doesn't make much of a difference, when the branches are close to each other, and when the branches remain separated forever after the initial split. Therefore everything said in above comments is right. However, that's not the complete picture.

• At my work, older maintenance branches are not separate from newer maintenance branches or main branch. Every older branch is merged into every new branch after each bugfix on one of the older branches. That way cherry-picking is not necessary at all (unless someone didn't start the bugfixing on the oldest possible branch), because the same commit lands in all still actively maintained branches. Bitbucket can fully automate the merging after the first commit: https://confluence.atlassian.com/bitbucketserver/automatic-branch-merging-776639993.html
• Even if 2 branches remain separated, different people cherry-picking many changes in another order than initially applied also leads to very confusing merge conflicts (if multiple commits touched the same files). Git then doesn't see changes in one file "stacked onto each other" during the merge, and will typically produce multiple conflicts, where the second conflict may look like an inverse of the first conflict that you already solved before etc.

Both aspects are probably not relevant here. I had assumed that the initial suggestion was about a branching model where old branches get merged into the newer branches, but I was surely wrong about that for the platform project (while other projects do that). So for separate branches my suggestion might have led to more confusion than being useful. Sorry @jonahgraham

PS: If someone doubts that this kind of "merge everything to the next newer branch" actually works, because of version number changes and similar: If you don't want one of the changes on the newer branch, you just revert it after the merge. That way this commit has no effect, but still the old branch is always merged.

[akurtakov]

Is there anyone actually willing to invest into doing builds from old branches? If not the whole discussion comes pointless.
Right now Eclipse Platform has single stream of development and that is master, as nice as it would have been to have maintenance branch and builds for end users I am not aware of anyone trying to make releng simpler with that goal in purpose.

[laeubi]

I think "older" more means RC branch of current release and master = next release, so there is no need to "stop-the-world" at the quiet periods.