You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2020/02/10 09:47:55 UTC
Numbering schemes for future releases
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Numbering schemes for future releases
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Feb 10, 2020 at 2:34 PM Rémy Maucherat <re...@apache.org> wrote:
> On Mon, Feb 10, 2020 at 1:08 PM Martin Grigorov <mg...@apache.org>
> wrote:
>
>>
>>
>> On Mon, Feb 10, 2020 at 1:56 PM Rémy Maucherat <re...@apache.org> wrote:
>>
>>> On Mon, Feb 10, 2020 at 12:05 PM Martin Grigorov <mg...@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
>
>
Re: Numbering schemes for future releases
Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Feb 10, 2020 at 1:08 PM Martin Grigorov <mg...@apache.org>
wrote:
>
>
> On Mon, Feb 10, 2020 at 1:56 PM Rémy Maucherat <re...@apache.org> wrote:
>
>> On Mon, Feb 10, 2020 at 12:05 PM Martin Grigorov <mg...@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
Re: Numbering schemes for future releases
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Feb 10, 2020 at 1:56 PM Rémy Maucherat <re...@apache.org> wrote:
> On Mon, Feb 10, 2020 at 12:05 PM Martin Grigorov <mg...@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
>
>
Re: Numbering schemes for future releases
Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Feb 10, 2020 at 12:05 PM Martin Grigorov <mg...@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
Re: Numbering schemes for future releases
Posted by Martin Grigorov <mg...@apache.org>.
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.
Martin
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Numbering schemes for future releases
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Feb 12, 2020 at 10:55 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Konstantin,
>
> On 2/12/20 11:25 AM, Konstantin Kolinko wrote:
> > For me aligning Tomcat version and Jakarta EE is not a practical
> > goal. It did not happen before.
>
> The contemporary Tomcat and Java EE versions have never been this
> close before.
>
> > It may occur naturally, but I do not like to aim for it.
>
> Fair enough.
>
> > I think that nowadays it is OK to have a major branch that is not
> > a LTS one. It has not happen in Tomcat yet, but It happens in many
> > other projects.
>
> Tomcat 8.0 was somewhat hurriedly dropped in favor of 8.5, so I think
> there is definitely some precedent.
>
8.0 is four years of stable releases. I guess it's short by Tomcat
standards, but that's about it. Tomcat 5.5 and 4.1 also took over the
previous branches with large changes (Java 1.5 and the coyote connectors,
respectively).
So D seems a bit ahead in the "voting" right now.
Rémy
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5EdEAACgkQHPApP6U8
> pFh0vQ//cDFDwDiyudzJf9rHwoOjiG/IFjlm/4KtZEJlDkj4bWk/h7oex7e9VUSW
> UQ6P4BrVSXfsVz0uCXj20bB+qApS+b+lGHQqEGUUT8HwZn2oByHb8WBN92QVrQ6g
> rr7bOk3yHpCM0mILw1GaI6pbloroCcBVMydcqUN51BDdCqwCJqGeGZLx4NZd+BD4
> ElYJCSAJP9Em44uz0S9gxbcClPLMHMt3Yq3LD7wdFimBh9EWROv4xQXGuJKHsa3A
> xOilqc7XNA4E/SiqAAm7evdeBxnuB4Aijek0xWephQvQ4QMtXxVvRFOXM1Nmejsx
> xJPIcYlHzJWFsjpsG7UKG57wIK3WfAEGmZut50tDTFuMxfABsqgYnbuLxUW0XTyT
> l3nqVlX4CxEmNrEUVy8C2ceWIhIAKT1HAFzmL0kLwmA6wP69WUzLsVahUFeMCWuQ
> fSsMoNSW+DoXjcnD0zGu0l5Vw/ewnv8SHaKMN7YrlnfyAR/wOapjGOAqTVX+MOQV
> TZvPyDdA6ff9JPqByw9yRtpYKdkHTBbp/7mbRKBSTTL2+a9qn/sTEjqQHpIqJ/Bf
> VmmSK0eoieem9G0tEuRzUQiaGMD6Uu7du3XYuEJCXPcO+i2YVLdDS6F921jKh/O+
> CjOPBW81rTn+L0KzR3MxcSsXzUHwg1D9XqLtbbFvkJ1COW68HBQ=
> =ARzV
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Numbering schemes for future releases
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Konstantin,
On 2/12/20 11:25 AM, Konstantin Kolinko wrote:
> For me aligning Tomcat version and Jakarta EE is not a practical
> goal. It did not happen before.
The contemporary Tomcat and Java EE versions have never been this
close before.
> It may occur naturally, but I do not like to aim for it.
Fair enough.
> I think that nowadays it is OK to have a major branch that is not
> a LTS one. It has not happen in Tomcat yet, but It happens in many
> other projects.
Tomcat 8.0 was somewhat hurriedly dropped in favor of 8.5, so I think
there is definitely some precedent.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5EdEAACgkQHPApP6U8
pFh0vQ//cDFDwDiyudzJf9rHwoOjiG/IFjlm/4KtZEJlDkj4bWk/h7oex7e9VUSW
UQ6P4BrVSXfsVz0uCXj20bB+qApS+b+lGHQqEGUUT8HwZn2oByHb8WBN92QVrQ6g
rr7bOk3yHpCM0mILw1GaI6pbloroCcBVMydcqUN51BDdCqwCJqGeGZLx4NZd+BD4
ElYJCSAJP9Em44uz0S9gxbcClPLMHMt3Yq3LD7wdFimBh9EWROv4xQXGuJKHsa3A
xOilqc7XNA4E/SiqAAm7evdeBxnuB4Aijek0xWephQvQ4QMtXxVvRFOXM1Nmejsx
xJPIcYlHzJWFsjpsG7UKG57wIK3WfAEGmZut50tDTFuMxfABsqgYnbuLxUW0XTyT
l3nqVlX4CxEmNrEUVy8C2ceWIhIAKT1HAFzmL0kLwmA6wP69WUzLsVahUFeMCWuQ
fSsMoNSW+DoXjcnD0zGu0l5Vw/ewnv8SHaKMN7YrlnfyAR/wOapjGOAqTVX+MOQV
TZvPyDdA6ff9JPqByw9yRtpYKdkHTBbp/7mbRKBSTTL2+a9qn/sTEjqQHpIqJ/Bf
VmmSK0eoieem9G0tEuRzUQiaGMD6Uu7du3XYuEJCXPcO+i2YVLdDS6F921jKh/O+
CjOPBW81rTn+L0KzR3MxcSsXzUHwg1D9XqLtbbFvkJ1COW68HBQ=
=ARzV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Numbering schemes for future releases
Posted by Konstantin Kolinko <kn...@gmail.com>.
Hi!
пн, 10 февр. 2020 г. в 12:47, Mark Thomas <ma...@apache.org>:
>
> [...]
>
> 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: [...] Option D:
1. If we are going to release a version of Tomcat for Jakarta EE 9,
I need a proper version number to name it, and "10.0.0" is not such a number.
As such, I am strongly -1 to option A.
2. Option C looks like a waste. It may occur naturally if it takes too long to
stabilize Tomcat and Jakarta EE 10 comes sooner.
I am -0 to Option C.
3. I like both "B" and "D".
I think that we can go with "D", but be prepared to switch to "B" in
case if Jakarta EE 10 occurs to be much different from Jakarta EE 9.
The deciding point for me will be whether Jakarta EE 10 allows running
with Java 8.
If it does not, I would prefer option "B" rather than "D".
Re: Mark's
> I don't like option B because the off-by-one issue between Jakarta EE
> and Tomcat.
For me aligning Tomcat version and Jakarta EE is not a practical goal.
It did not happen before. It may occur naturally, but I do not like to
aim for it.
Offtopic: I had a similar discussion in another project several years
ago, and the outcome was that there is no need for an alignment (The
discussion was about aligning TortoiseSVN with Apache Subversion).
[1][2]
[1] https://subvserion.markmail.org/thread/s3d7sz4percblwbv
[2] https://tortoisesvn.markmail.org/thread/f63wx54jzclngojo
Re: Remy's
> -1 for option B also because the EOL of that "major" Tomcat 10 branch may be way too quick for a major branch.
I think that nowadays it is OK to have a major branch that is not a
LTS one. It has not happen in Tomcat yet, but It happens in many other
projects.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Numbering schemes for future releases
Posted by Mark Thomas <ma...@apache.org>.
On 11/02/2020 14:15, Mark Thomas wrote:
<snip/>
> 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.
My reading of the thread since I sent this message is that there is
consensus to go with option D. It isn't everybody's first choice but it
is the choice that everybody can accept.
Therefore, a little later than planned I'm going to go ahead with the
steps I outlined above.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Numbering schemes for future releases
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Numbering schemes for future releases
Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Feb 10, 2020 at 10: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.
>
-1 for option B also because the EOL of that "major" Tomcat 10 branch may
be way too quick for a major 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)
>
D looks good to me for the flexibility. I suppose/hope/would think the
people at Eclipse will want to provide something useful sooner rather than
later, so A seemed acceptable to me, but you never know. You know, three
years later, you could find yourself still releasing 10.0.0.26. Ooops.
10.0.26 would look better, if that unfortunate scenario happens.
The 10.0 branch does imply some amount of support though, so it likely
won't be possible to phase it out as fast as in Option A or C. It's not
nearly as bad as B of course.
C would look the best to me if there was a guarantee on the EE 10 release
schedule being quick. Thinking about it again today, I think that's a huge
unreasonable risk.
Rémy
>
> Thoughts?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Numbering schemes for future releases
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Coty,
On 2/10/20 8:37 AM, Coty Sutherland wrote:
> On Mon, Feb 10, 2020 at 4:48 AM Mark Thomas <markt@apache.org
> <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)
>
>
> I think I prefer option A, with D as a secondary. Initially I liked
> C the best, but given the conversation I agree that it's probably
> not the best way forward.
I think you have captured the essence of this conversation, here:
> Either way we do it is going to be somewhat confusing for folks I
> think, at least initially, but the options we have all seem pretty
> easy to explain.
Given that confusion is inevitable, let's go with the option that has
the best steady-state outcome, which is option A -- where the Tomcat
version lines-up with the Jakarta EE version number.
Back when Tomcat 3/4/5 were released, the Java EE version numbering
was unpredictable and it wasn't obvious that Tomcat versions followed
various combinations of specifications. Now that Tomcat is essentially
following a numbered-bundle of specs (e.g. "Jakarta EE 10") instead of
collections of individual specs (Servlet, JSP, EL, WebSocket, JASPIC),
it makes much more sense for our version numbers to b as
easily-trackable as possible.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5BcbcACgkQHPApP6U8
pFiQ8hAAnpUQ6xBi2x/MrcmlzjzvJvfJCHZ+KICaWvWuKoOXfk45iiuDzJZwWR0/
WKm5vZ2oDEmjQNSkqiaUHklCXm3lNNJ+/Epc1ikZ19cfoWo++KeyeQG995ePvED8
KPh7z5OtNaDaUi7ciJjKiORCJH4BtAlnBXlZBpcnTZ9I/YbRzQjSgYjeMPiUEDnY
J5wQq/jNnutAiU1B4pzcFRGKw82yetA41isvGdyn3dLkWaSFzKAkQAbvGrOPrlER
KuNrhJUgwCo7R9KAzzv58QSITn+kBt+3Y6CMAxRe65uOaozNEZJ7cPbf2fr3otSR
UOB7m8sTYdHBsMEMKRbUw9Lw0SFRGHKWR5WxFam8JlvYcwQeQwnY3dj5MiDNZvoV
ybeho0H61AWluZbmRgP/B9Ev3R2KhpEVwTJaDMJcy/dbXeogTONLVmqUesb6GhxA
HC+pMlZV9Zqe4p7sdR2mBLjVNQYKiRKCOzPkRowzRS2kLrgsQLizn6tgDRjPwzSu
UHWkFku3L1/5bufpESwv8UwVe875uqjkjPOQ6UvLlsErt4tSNWuaLRZxzaMHIGR2
lEs0FfvIfuLHtnmcA9cib4/gf80O9wI3dlyVM16qBLHwT+DGFb0qfDIG8Bt/oHg0
Q04Vs+nFSZ8wBVEbOmYrmg3O78KQeBRU1IB1TQVyikqBJTUybQc=
=sXCR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Numbering schemes for future releases
Posted by Coty Sutherland <cs...@apache.org>.
On Mon, Feb 10, 2020 at 4:48 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)
>
I think I prefer option A, with D as a secondary. Initially I liked C the
best, but given the conversation I agree that it's probably not the best
way forward. Either way we do it is going to be somewhat confusing for
folks I think, at least initially, but the options we have all seem pretty
easy to explain.
>
>
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>