Couple of quick responses, and then let other people respond :-) ... On Sat, 13 Jun 2020 at 17:59, Laszlo Kishalmi <[email protected]> wrote: > On 6/13/20 2:12 AM, Neil C Smith wrote: > > I think we had problems between > > 9 and 10 like this, where the same issues recurred in 10? > Well, it might happened, maybe due to human error (me). However as far > as I remember, there were generally no problem cherry picking changes > from the master,
No, nothing to do with you - there were a few times I remember noticing things that were fixed in release branches were not properly fixed in master because by the time of the fix they'd diverged. ie. bugs fixed in 9 were not as well fixed in master before 10. To me, it's the linear history, that next release builds on the previous release, that's most useful about freeze. > > We could stop having LTS, > > Well, I do not know, I'd probably open a separate discussion on that > topic. Yes, maybe, let's see where this goes - the question of why we have one and what it is keeps coming up. Of course, answering the latter might help with the former. > > If we keep LTS, we could have a month freeze again, then vote on a > > release candidate. > I'm not sure I understand this correctly, but: Let's do a 12.0 on master > like a regular feature release. but bring it just to beta release, then > release patches via UC. and once we think it is ready for release, do > another full release for voting and finally release that one (assuming > that it passed the voting round)? Yes, that's pretty much what I meant (and badly described)! I'd call it release candidate though. Currently we have betas that are not voted on and distributed direct from the build. Theoretically, under ASF rules those links should not go beyond dev@. A release candidate that was properly voted on and distributed via mirrors could be much more widely publicised. > > A general > > principle of, if the PR is ready to merge on Monday, it's in the beta > > on Wednesday (or whatever days suit the RM) is something I'd > > personally like to make a documented part of the release process. > Go for it, document it. Generally I like the idea of being more time > based. On the other hand we are still a bunch of people doing most of > the work in our free time, so I'm bit skeptic on that, but we never know > if we won't even try it. Yes, personally I find it easier to block out a regular slot in the diary for the free time stuff than to pick it up piecemeal, so that's why I did it that way. I realise that we're all in different work / free time scenarios so it might not work for everyone. 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
