Me too, 3 months sounds good and makes us competitive to e.g. IntelliJ. VS Code has once a month (This is my personal Dream but I know, that this is not doable, with our process, netcat, etc.). 6 Months is way to Long. Remember, that we don’t have only Java, so to make a release only when a new JDK is coming out, is inacceptable. Because we have C/C++, JS, HTML, CSS, PHP etc. etc. So please think out of the box, NetBeans is not a Java DIE anymore for years.
We have patch Levels which is great but for new Features, I don’t know whether the patch Level is working. So Long Story short: 3 months, IMHO. Cheers Chris Von: Jan Lahoda Gesendet: Mittwoch, 27. Juni 2018 10:02 An: [email protected] Betreff: Re: [DISCUSS] Proposed Release ProcessWAS: Merging back netcat@ intothe dev@ mailing list I'd personally prefer faster releases (i.e. 3 months or so). I'd suggest to try to minimize cherry-picking/backporting. One possible way is to have a window for merging features, and then only do stabilization/bugfixes in master for some time, and only then (closer to the release) do a branch, and only cherry-pick a limited # of changes. I believe this is the approach that has been used in NetBeans for quite some time, and, to me, it seemed to work fairly well. I believe the branching occurred a months (or so) before the release, but I may be wrong on that. But it surely is not the only process we could follow. Jan On Tue, Jun 26, 2018 at 6:01 PM, Neil C Smith <[email protected]> wrote: > On Tue, 26 Jun 2018 at 13:34, John McDonnell <[email protected]> > wrote: > > > > Might every 3 months be pushing it a little? > > > > We'll constantly be in a state of picking fixes for release -> testing -> > > fixing -> release -> picking fixes for release, etc.. > > > > Something like 6 months is a little more relaxed as it gives us about 4 > > months between releases to make changes, introduce new features to the > IDE, > > without rushing. > > Funnily enough, my view is that 3 months would be more relaxed, > because there's less stress to rush a new feature if it's not ready > when there's a new release cycle imminent. Likewise, this was > suggested on the basis of master being kept relatively stable, with > new features mainly being developed in branches until they're ready > for wider testing. With cherry-picking of changes from master into > the release branch (like is happening now), I don't see why all these > things cannot happen in parallel. A bit more Release Early, Release > Often, with some NetCAT still in the mix! ;-) > > I think I'm up to 4c. > > 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 > > > >
