Am 25.07.18 um 17:40 schrieb Maciej Sumiński: > Nobody forbids working on new features in separate branches that we will > start merging once 5.1 is released and 6.0 development cycle starts. I > have already started a few branches for v6 features, but they need to > wait now.
That's what I mean, why I need to wait? In recent days this is for me a mismanagement and such things are mostly not needed. Those are feature branches made for so people can continue on their work continuously. You will need to merge the related changes into the other branches. Remember the link to the website I made, it show this nicely. https://nvie.com/posts/a-successful-git-branching-model/ > I simply rebase them from time to time, but it is not a big deal so > far. This will get annoying and frustrating the more often you need to do this. It may be not a big deal for you as a core developer because you know mostly every detail in the source, but for people from outside it's unneeded load to do such rebasing again and again. I've done this for thunderbird for about a half year before I was going further. This was really frustrating. > I anticipate GTK3 fixes to be ready in 1-2 months from now, > I am not sure if the delay is significant enough to keep this discussion > going on. This is a decision you have to make. For me GTK fixes are a thing you of course will need to have also in later version so the typical solution is to merge theses things into the current master branch. No need for cherry-picking. > We have already experienced a significant overhead in late v5 cycle due > to porting certain v4 fixes to v5 branch or vice versa. Imagine that we > keep working on 5.1 and 6.0 at the same time. I know such things from other projects, this is real life. Other projects have people which are responsible for release management. > I am sure we could right now dump enough code onto the 6.0 branch to > diverge it from 5.1 so much that porting fixes between them becomes > non trivial. Keep in mind that there is 5.0 branch that may need to > share some patches with the remaining branches too. Please notice > that *every* patch that we applied to 5.1 had to be applied to the > master branch as well via cherry-picking. You really wont do cherry-picking! Merging is the right thing here. KiCad is not the Linux kernel or Gnome, but look how these projects are working. Both need to take care about older releases too. And many other projects also. If you keep up the branches in the core in sync it isn't that difficult to backport changes. > What are the benefits of maintaining 3 branches? Simply that every one can make progress without being slowed down due some technical reasons? It's all about organization. In the long run you will need at least two branches like before, so currently you will need also 5.0 to provide urgent fixes before any 5.1.x release is made. It's not that much more I guess. But again, it's up to you guys how you will organize your work, all from me are just suggestions based on experiences I made in the last decade while contributing to various projects. Let's stop here. -- Regards Carsten Schoenert _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
