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