I think folks tend to work of master branch so maybe something different could 
help some.

Was wondering if the “gitflow” model may help in the branching process.

http://datasift.github.io/gitflow/IntroducingGitFlow.html

https://nvie.com/posts/a-successful-git-branching-model/

Eric Bresie
[email protected]
> On September 4, 2019 at 6:06:59 AM CDT, Neil C Smith <[email protected]> 
> wrote:
> 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
>
>
>

Reply via email to