On Mon, Feb 10, 2020 at 1:08 PM Martin Grigorov <mgrigo...@apache.org> wrote:
> > > On Mon, Feb 10, 2020 at 1:56 PM Rémy Maucherat <r...@apache.org> wrote: > >> On Mon, Feb 10, 2020 at 12:05 PM Martin Grigorov <mgrigo...@apache.org> >> wrote: >> >>> Hi, >>> >>> On Mon, Feb 10, 2020 at 11:47 AM Mark Thomas <ma...@apache.org> 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? >>>> >>> >>> From the above I like option C. >>> It the release of Jakarta EE 10 is delayed for some reason we can switch >>> to option D. >>> >>> One more option: >>> Option E: >>> Jakarta EE 9: 9.99.x (or 9.999.x) >>> Jakarta EE 10: 10.0.x >>> Jakarta EE 11: 11.0.x >>> Java EE 8 : 9.y.x (where y == major Tomcat version) >>> >>> It is a bit ugly but some projects have used such version scheme to >>> emphasize that it is a transitional release. >>> >> >> > Indeed it is getting complicated to understand the versions here. > > >> Well, this won't work as the plan for the 9 branch [the last branch on >> javax] is to track the API changes from the last major branches using minor >> branches. So 9.10 [tracking the EE 10 branch], then 9.11, then 9.12, and so >> on but still based on >> > > What do you mean with "So 9.10 [tracking the EE 10 branch]," What is EE 10 > here ? Javax or Jakarta ? > Since Oracle won't lead EE anymore then it should be Jakarta EE 10. But > Jakarta EE 10 will (hopefully) be implemented in Tomcat 10.0.x. What > exactly will go in 9.10.x ? > This is explained in the document: https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering 9.10: Continues to support Java EE 8 with Tomcat API identical to latest Tomcat 10.0.x 9.11: Continues to support Java EE 8 with Tomcat API identical to latest Tomcat 11.0.x 9.N: Continues to support Java EE 8 with Tomcat API identical to latest Tomcat N As I said, this is to be able to maintain an up to date Tomcat release branch that still uses Java EE 8. If nobody ends up caring, this branch will of course be dropped eventually, but I don't think that's the most likely scenario. > > >> Java EE 8. This is an attempt to extend the support period of the 9 >> branch even further and keep Tomcat 9 relevant with the new features from >> the main most recent branch. So you could propose 9.9, possibly, but 9.99 >> or 9.999 or other random number doesn't fit. Then, the most important >> problem is that the 9 branch means Java EE 8 support, and you would be >> polluting it with a Jakarta EE release. >> So unfortunately that option E doesn't work at all, despite its apparent >> similarity with option D. >> > > The idea to use 99 or 999 is to use a number that is far ahead and that it > won't ever be reached by the normal releases, like 9.1.x, 9.2.x, etc. > > Right, but then it is dropped and it goes back to 9.10. So that doesn't work very well for me and I prefer using 10.0 and 10.1 instead (option D) of 9.99 and 10.0. Rémy
