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 >
