On Wed, 9 Sep 2020 at 20:26, Matthias Bläsing <mblaes...@doppel-helix.eu> wrote: > Having a "next" branch might help with that. But we have to be > prepared, that merging "next" will then create merge conflicts. Raising > a new problem: Who merges "next"?
The release manager, probably, in discussion with the authors of any conflicting commits? Are there any circumstances where a merge conflict is not caused by a fix in the release branch and a fix/feature in the development branch diverging? In which case, the RM has to work with the author to resolve the problem one way or the other, whether we integrate in next or master. It doesn't change the problem of the branches diverging. Personally, I'd rather handle that in the week following a release vote and keep master's existing role, rather than doubling the workload of integrating fixes up to the release. On Thu, 10 Sep 2020 at 06:53, Laszlo Kishalmi <laszlo.kisha...@gmail.com> wrote: > Still it is hard to start work on features/fixes that depend on each other. Agreed. One way or another we need to have the same fixes in two branches so that development and release can progress - either master+release or master+next. But the latter is a tweak to a process that in other respects is working OK, the former requires rethinking quite a lot of what we've been doing for 5 releases. Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
