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 For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
