To me it makes sense to have NB reflect the level of Java implemented. For example, features of JDK 11 can be added incrementally to NB 9.1, 9.2, etc. (schedule is irrelevant to me -- every 3 months is fine) but when the full function of JDK 11 is included then NB 11 should be released. I assume we're going to skip JDK 10 at this point. Releases like 2018.3 tell me nothing about what the product includes. But if Java moves to that naming scheme then NB should move to that scheme to indicate what is implemented.
On Tue, Aug 7, 2018 at 1:46 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com.invalid> wrote: > Hi all, > > We've discussed this informally, i.e., the topic of the release > cycle/cadence, a few times over the past months. > > Let's nail it down as far as possible so that we can give clarity to our > users about our intentions and also to enable us to organize features > coming in through donations and otherwise into releases. > > https://cwiki.apache.org/confluence/display/NETBEANS/ > Apache+NetBeans+Release+Cycle > > Right now, we have a clear suggestion around in which month of the year we > will release. I.e., the Apache NetBeans (incubating) 9.0 release was our > August release (and we even managed to release it a few days early, in > July, hurray!). So, this year, we will have another release in November, > that's our next big target, if we agree with the above proposal. > > 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. > > Anyway, thoughts welcome, > > Gj >
