Hi All, I meant to kick this off a couple of weeks ago, but .. work .. apologies.
So, hardly has the dust settled on NB 11.1 and the feature freeze date for NB 11.2 is just around the corner! From my perspective, I think the release process for NB 11.1 went well, with a few caveats, but I wanted to open up some discussion if people want to suggest possible tweaks for NB 11.2. I think overall NB 11.1 showed we can meet our quarterly release target, and a month is a realistic gap between freeze and release for non-LTS. I realise we ended up a week later with NB 11.1, but this was almost entirely due to allowing JavaEE / Payara support to go in a week after freeze. That was my call to suggest, and I still think the right one, but does highlight that we should try to get features in earlier rather than later in the release cycle. It also highlighted some issues we have with spurious failures in Travis leading up to the freeze date, only one of which was an actual problem. >From my perspective, freezing master to anything but fixes intended for the release, and not cherry-picking, made things much simpler. It also ensured we started NB 11.2 development (mostly!) from the stable release state. How much of an issue was that for continued development though? Do we definitely continue with that as was for 11.2? We unfortunately had to revert a PHP 7.4 PR not intended for release, and I take some responsibility for not communicating the master freeze better. However, how did setting up a separate branch on the repo for PHP 7.4 after that work in practice? Is this something we should encourage more of anyway, whether in freeze or not? For NB 11.1 we needed a release branch from the start of the process due to various changes that need to be made. Further work since may mean that differences between release branch and master will be less, but for NB 11.2 I think we'll still branch at freeze?! I wasn't sure when kicking off the process the best approach to merging from master to release branch, and decided to try pull requests. This actually worked really well, as by opening a pull request early it meant that all merges to master got tested against the release branch automatically, and we ended up with a page with a clear view of differences from one beta to the next. I think that's something to continue for NB 11.2. With the first (failed) voting candidate I made the mistake of fixing a bug (in Payara Micro) from the previous beta, which in turn exposed another bigger one! We should probably aim in future for no code changes from final beta to voting candidate. If a legitimate critical or blocker is opened against the beta, then we should always have another beta with the fix prior to release voting?! There was some discussion afterwards on need to pull Maven artefacts vote because of implementation versions / whether we vote on all binaries / whether all binaries are included in the release vote. Personally I still think we should keep vote to sources only, and just have oversight on binaries from a few PMC members. But, if we are voting for binaries we will need to decide whether to have one (sources and binaries) or two (sources then binaries) votes. And if we include binaries in the release vote, we'll need to rethink the voting template and instructions we've used for all previous releases to emphasise that binaries are *not* irrelevant to the vote! >From the perspective of not landing major things in master close to freeze, or seeking a freeze bypass, are we in a position where we acknowledge C/C++ support isn't going to make it in to NB 11.2? I'm unfortunately really tied up until freeze date (Sep 15th) but am keeping some time free afterwards. Once I get my head around the new Jenkins task for release builds, which I assume we'll be using(?), I'm aiming to go for weekly betas again, hopefully mid-week, until we're ready for release vote. Maybe we'll see if we can even out the last one and get this one out a week early! :-) OK, that's my brain dump on it all - any thoughts to add? 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
