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
