On Mon, Feb 10, 2020 at 2:34 PM Rémy Maucherat <r...@apache.org> wrote:
> 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. > Thanks for the reference! If Tomcat was a library/framework I'd suggest to use Maven classifiers. Lately most of my applications use Tomcat as embedded server. It would be much more natural to add <classifier>javax</classifier> (for Maven) or to append ":javax" (e.g. "org.apache.tomcat:tomcat-embed-core:10.0.1:javax" for Gradle) But I don't see how this could work for the standalone downloads and the OS packages. > > >> >> >>> 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. > Fair enough! I don't see it as a problem. 8.0.x has been dropped (in favour of 8.5.x) and new releases of 7.0.x have been released since then. Since Tomcat does not follow SemVer but custom rules for X.Y.Z it is just a matter of documenting 999 as a transition release with short live that could be used by early adopters. Martin > > Rémy > >
