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 ? > 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. > > Rémy > >
