Hi Laszlo, Thanks for the proposal, if a balance between Neil’s perspective and yours can be found, that would be best — however, it sounds like you have a great way forward and that 12.2 is in good hands.
Thanks, Gj On Sat, 3 Oct 2020 at 18:44, Neil C Smith <neilcsm...@apache.org> wrote: > On Sat, 3 Oct 2020 at 16:44, Laszlo Kishalmi <laszlo.kisha...@gmail.com> > wrote: > > > So it has not died in my mind, but it is the time to bring up what's on > > > my mind. > > > > Thanks! Generally seems a good plan from my point of view - few > > comments below. No secret I probably prefer keeping master as the > > release branch, but not going to -1 this in the Lazy Consensus thread > > when you're ready for that. The existing schedule and amendments to > > it have been done that way, so do think we need to continue with that > > process though. > > > > > - create branches: release and release122 from master > > > > I hadn't considered this option, and the regular merges from release > > to master. This way of handling fixes does address most of my > > concerns about ensuring fixes are always included in master branch / > > following release, as well as potential duplication of a lot of PR > > effort. > > > > Minor thought - double check any regexes in the build to match release > > branches doesn't mind that branch name. May be safer to use something > > other than release. > > > > > - Merge the version bump PR to master > > > - Merge the branch-version bump PR to release122 > > ... > > > Also I'm not sure if the version bump at the beginning of > > > the release mode is a good place. > > > > Version bump for 12.2 is already done. It's the final commit in > > master before freeze ends in the current process. > > > > I would suggest version bump just on master after creation of release > > branches, assuming that doesn't add issues to merging fixes. > > Otherwise, keep until after release? Either way, needs to only happen > > on master. > > > > Same consideration to when sig test files get updated? ... > > > > > - release branch, if there is a fix wished to be seen in 12.2 put a PR > > > against the release branch, if possible no-API changes please > > > > Also see comments from Jaroslav from > > https://github.com/apache/netbeans/pull/2338#issuecomment-686633315 > > > > We should probably generate either the sig tests or the PR for them at > > branch point for merge to all branches. That way API changes can get > > proper review before release, and API problems (although not > > additions?) in fixes could be highlighted. > > > > > - PR-s to the release branch shall be at least marked with the 12.2 > > > milestone and request a review from the RM > > > > So all fixes need a base branch of release during each release cycle? > > But only one PR, one JIRA ticket, etc. because they'll be synced to > > master (by you)? > > > > Possibly need to document that well. Although easy enough to change > > in the PR UI, probably better to make sure the author has written and > > tested against the right branch first. > > > > > It's a pretty tight plan, please fill-in what I've missed, argue, > > > correct, etc. > > > > Best laid plans of mice .... :-) * Yes, seems tight, but a reasonable > > evolution of what we've done to date. All really comes down to how > > timely fixes are - August was not the best month for releasing in that > > regard. Good that nb-javac looks about ready for integration prior to > > freeze too - been a common delayer. > > > > * https://youtu.be/J_7SWUK7gd0 > > > > 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 > > > > > > > >
