As geertjan already said and I mentioned it as often as I can, NetBeans is more than Java, for years. I know atm It is only Java but the rest and more will come soon. So it doesn’t make sense to me to have NB 9 to set it to JDK 9 and Maybe 10 and then have NB 11 to JDK 11. If you see NetBeans only as a Java IDE then it could make sense to know what is inside, but no it isn’t only Java. So NB 9 or NB 10 or 11, is the same reason, where I don’t know what is inside as for NB 2018.2 e.g.
Cheers Chris P.S. Please think out of the box. Yes NetBeans started as a Java Project, but for I think now Maybe 10 years or so, it is much more than that. Von: Oliver Rettig Gesendet: Dienstag, 7. August 2018 16:36 An: dev@netbeans.incubator.apache.org Betreff: Re: AW: Apache NetBeans Release Cycle I like sync with supported JDK version but now we have 9.0 and this already supports JDK 10. Maybe the next releases can be 9.1, 9.2, 9.3, 9.4, 9.5 ... next version every 3 months If we have included all donations we can switch to 10.0 If netbeans supports JDK 11 then we switch to 11.0 and then we can stay in sync with JDK version. > We had the discussion earlier and afaik the Outcome was every 3 months to be > competitive and get more Features, fast in it. 6 months is far to Long, > when some competitors have it once a month or every 3 months. > > > Cheers > > Chris > > P.S. I’m fine with every 3 months to have 9.1, 9.2, 9.3, 9.4 and for Major > to have 10.0 or Maybe in years 2018.1, etc. Ubuntu does this for the month > like Ubuntu 18.04 (2018.04 – April) So NetBeans could have this too like > 18.08 then 18.11 smth like that. > > > Von: Neil C Smith > Gesendet: Dienstag, 7. August 2018 12:35 > An: dev@netbeans.incubator.apache.org > Betreff: Re: Apache NetBeans Release Cycle > > On Tue, 7 Aug 2018 at 09:46, Geertjan Wielenga > > <geertjan.wiele...@googlemail.com.invalid> wrote: > > However, a separate discussion is about release numbers. Our current > > release is 9.0. How do we decide to number the other releases? A simple > > proposal might be to have our major release in August of each year and > > then > > all then make all the other releases minor. However, that's just a > > thought, > > another one could be that we should simply consider how large the features > > are that we have added and base major/minor on that. Or we could try to > > follow the JDK release numbering more or less. > > I suggested the JDK version sync early on, and no-one else seemed keen > on that! :-) > > Taking a step back, what do version numbers mean for us? If they have > a semantic reason (pun intended), then arbitrarily having a major > version increase based on date seems strange. Unless we see August as > the time of year for decluttering deprecations? > > So doing it for major features might make sense, but how to define > what's major, and going with incremental 3-monthly releases when > features ship when ready, at which point do you decide the next > version number? What if the "major" feature slips? > > We could have a purely incremental version number, which seems simple, > and we can start catching up with Firefox / Chrome. > > We could go with the Ubuntu-esque (and JDK rejected) date versioning? > > Or we could take the Linus' approach to kernel numbering, and update > the major version on a whim because the minor seems high! :-) > > Personally, I'd be inclined to purely incremental. > > 2c > > Best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org >
