AW: [DISCUSS] Proposed Release ProcessWAS: Merging back netcat@ intothe dev@ mailing list

[Christian Lenz <ch...@gmx.net>]

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: dev@netbeans.incubator.apache.org
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 <ne...@apache.org> wrote:

> On Tue, 26 Jun 2018 at 13:34, John McDonnell <mc...@gmail.com>
> 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: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: [DISCUSS] Proposed Release ProcessWAS: Merging back netcat@ intothe dev@ mailing list

[John McDonnell <mc...@gmail.com>]

Cool, seems the general consensus is 3 months, and so lets look at what the
plan for those 3 months could be:

I've updated my suggestion to show how I think a 3 month cycle would work:

Day 0-90: Development Continues and takes place in branches - as normal
Day 30: dev mailing list agrees to initiate a release. PR's not merged into
master at this time are identified and merged/reviewed as needed &  Code
Branched into specific release Branch & Jenkins updated
Day 30: NetCat Announced + Week of signups
Day 30-36: New and Noteworthy page created/updated (Useful for NetCat
process to see what new features they need to update their test specs
with) + Branding changes in the branch, etc...
Day 37: Test Spec Review Starts
Day 44-51: Last of the PR's are merged into the release branch(and master)
Day 44-51: Release Candiate 1 is Built & NetCat Testing Phase Starts
Day 74-81: Testing Ends (roughly 30 days of testing?)
Day 81: 72 Hour NetCat Community Acceptance Vote (use to be a survey, but I
assume now it needs an email vote)
Day 85: 72 Hour PPMC Vote
Day 89: 72 Hour IPMC Vote
Day 94: Release

I might be wrong here, but when we come out of incubation, we dont need the
IPMC vote so we could be releasing on day 89, then...

Regards


John

On Thu, 28 Jun 2018 at 08:14, Christian Lenz <ch...@gmx.net> wrote:

> 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: dev@netbeans.incubator.apache.org
> 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 <ne...@apache.org>
> wrote:
>
> > On Tue, 26 Jun 2018 at 13:34, John McDonnell <mc...@gmail.com>
> > 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: dev-unsubscribe@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
>