Thanks to everyone that has expressed an opinion so far. If you have a view and you wish to express it, now is the time to do so.
I've read through all the responses to date and my reading of those responses is: - A has strong support but also one strongly against - B has low support and several against - C has moderate support but several concerns about Jakarta EE 10 timing - D has moderate to strong support Option E was also proposed but did collect wider support The strong objection to A suggested either B or a variation on C/D as acceptable alternatives. The 10.0.0.0-M1 vote has been running for 3+ working days and this thread for 1+ working days. As previously stated, I'm happy to *briefly* delay the first Tomcat 10 milestone but I really don't want to delay more than a few days. Of course, if the PMC members feel I am rushing this release unnecessarily then there is always the option to vote against the release. Given all of the above, I propose to do the following: - Cancel the 10.0.0.0-M1 release vote - Give this thread until 10.00 UTC 13-Feb-2020 (just over 72 hours from when it started) to collect additional views - Assuming (and it is a big assumption) that additional views expressed are broadly consistent with the views expressed to date, tag 10.0.0-M1 and start a release vote. - If the additional views expressed are not broadly consistent with the views expressed to date (or people change their minds) then we'll have to assess where we are at the end of 72 hours and figure out a plan to move forward at that point. This approach rules out options A, B & E but leaves us free to choose between C, D or a variation at a later point when we can make that choice with a better idea of Jakarta EE 9 adoption rates, Jakarta EE 10 plans, etc. Mark On 10/02/2020 09:47, Mark Thomas wrote: > Hi, > > I thought it would be useful to re-open the discussion on this. If there > is a better plan that the one we currently have I'd like to try and find it. > > I'm happy to hold off on the current 10.0.0.0-M1 release for a few days > to give us time look for a better numbering scheme and so we have the > opportunity to pull the 10.0.0.0-M1 release if necessary. > > I have tried to express the various options I have seen proposed in a > similar way so we can compare them. If I have missed one or you think of > a different one then please post it. > > Option A: The current plan: > Jakarta EE 9: 10.0.0.x > Jakarta EE 10: 10.0.x (x>=1) > Jakarta EE 11: 11.0.x > Java EE 8 : 9.y.x (where y == major Tomcat version) > > > Option B: Continue with existing numbering > Jakarta EE 9: 10.0.x > Jakarta EE 10: 11.0.x > Jakarta EE 11: 12.0.x > Java EE 8 : 9.y.x (where y == major Tomcat version) > > > Option C: No stable Jakarta EE 9 release > Jakarta EE 9: 10.0.0-Mx > Jakarta EE 10: 10.0.x > Jakarta EE 11: 11.0.x > Java EE 8 : 9.y.x (where y == major Tomcat version) > > > Option D: > Jakarta EE 9: 10.0.x > Jakarta EE 10: 10.1.x > Jakarta EE 11: 11.0.x > Java EE 8 : 9.y.x (where y == major Tomcat version) > > > My own thoughts: > > I don't like option B because the off-by-one issue between Jakarta EE > and Tomcat. It is manageable at the moment but I worry that it will > cause confusion once we have the 9.y.x branch. > > I don't like option C because I think we need a stable, supported, > passing the TCK Jakarta EE 9 release. Also, Jakarta EE 10 is meant to > follow shortly after Jakarta EE 9 but what if it doesn't? > > For me, the choice is between A and D. If Jakarta EE 10 is very soon > after Jakarta EE 9 then I think option A is better. However, D isn't > that far behind and as soon as Jakarta EE 10 doesn't follow shortly > after Jakarta EE 9 I think D begins to look better. As I think about it, > the EOL decision we make for Jakarta EE 9 support depends a lot on how > quickly Jakarta EE 10 follows and I think D gives us more flexibility. > Finally, D is more consistent with how we have done things in the past > (4.1.x, 5.5.x, 8.5.x etc) > > Thoughts? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
