Please revise your release flow

ReDetection commented 5 years ago

Disclaimer

This is the fourth time I review this text and I try to make it as calm as possible and remove all the hate speech. I appreciate the work you've done to make this app a reality and have no expectations, but I have a suggestion for your team to consider.

Summary

Being a company who run our own mattermost instance and have our own push server with own app and own push certificates, we have slightly different configuration in the working tree. Every merge of release branch causes a lot of conflicts, because of the way you prepare releases. Please see details below.

Expected behavior

Merge of your release branch into our company branch goes well, only having incompatibility in the configuration files or when your changes overlap our changes.

Observed behavior

Merge of your release branch into our company branch goes bad, always having a lot of merge conflicts in the unrelated code – basically your own code conflicts with your another code. I have to solve this on my own, that is usually 40+ files to solve.

You can easily replicate this pain if you merge let's say v1.20 into v1.18 branch. In ideal world this should be a conflict-free merge and in fact it is the case for the most projects.

Possible fixes

At the moment you have to cherry-pick fixes from one release branch (e.g. v1.17) to all newer release branches (e.g. 1.18, 1.19) and the development branch. If you merge v.17 into v.18 you this will not only make it simpler for you to reapply conflict fixes in newer branches, but also streamline commits propagation into branches, and also this will fix release management for the companies like us who run own instances.

ThiefMaster commented 5 years ago

Assuming they are using the same flow as used in webapp/server, a git rebase --onto might help you!

For example, to apply my changes to 5.12.0, after they've been on 5.10.0, I use git rebase --onto v5.12.0 v5.10.0.

ReDetection commented 5 years ago

Yes, this is possible workaround and in fact I do it when there are too much of the conflicts to resolve in a reasonable time. Still, it has downsides too:

it produces unnecessary commit duplicates – all versions would have same set of changes on top of them
in order to keep organized, I would need to have my very own tags which basically duplicate yours but have same set of changes on top

Please consider this Issue not as a complaint (though it is one) but as another point against current branching model of the mattermost team. It is a GIT, not SVN, so why to use it as if it is SVN? You're loosing the beauty of GIT: it's seamless merges. :)

I saw https://developers.mattermost.com/contribute/getting-started/branching/ but unfortunately it has no reasoning behind. Though I did not talk with anyone in the chat – sure this will be ignored as soon as my message goes away from the screen – everyone has tickets to do, not a chat to read.

JtheBAB commented 5 years ago

It was a theme yesterday at the dev meeting:

ReDetection commented 4 years ago

Hi. I wonder did it go any further since your last message? Or maybe you have some schedule to describe some reasoning in the wiki?

JtheBAB commented 4 years ago

I think @enahum need to answer this

amyblais commented 4 years ago

I asked our devs about this and they said that having merge conflicts was a known issue when we decided to adopt this branching policy.

A workaround is that you can rebase your branch instead of merge the following release's branch to avoid merge conflicts. I can open a doc PR to update the existing documentation with this tip.

enahum commented 4 years ago

Going to close this issue as it hasn’t had any recent activity

mattermost / mattermost-mobile