On Fri, 17 May 2019 at 20:35, Jan Lahoda <[email protected]> wrote: > I'd like to ask: is there a plan for a "next" branch to which one could > merge stuff for the next release while the master is closed (and which > would be automatically merged into master when the merge window would > open)? As master is going to be closed for extensive periods of time, it > feels there should be a place where work could happen (rather than managing > private branches that are effectively done, but cannot be pushed/merged > anywhere, as the master is closed).
Well, one question would be, what did you have in mind when you originally suggested it?! :-) I wondered about this myself, but left it out for now. How useful / necessary does it feel in practice? What are the downsides? eg. is it simplifying the release merging process just to end up complicating it elsewhere? What work cannot happen in the context of pull requests? Could we set up various feature branches on a case by case basis where there's a need to merge interdependent private branches together to work on? I guess my thought was not closing master completely for all of that time - just concentrating on stabilisation merging only. We could rethink it completely? Or still do a release branch when we're closer to the release date? Just trying to get cherry-picking out of the process as much as feasible, and make sure release and master fixes tie up. Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
