Re: Tomcat next and Jakarta EE

[Mark Thomas]

On 28/11/2019 10:21, Rémy Maucherat wrote:
> On Thu, Nov 28, 2019 at 10:51 AM Mark Thomas  > wrote:
> 
> On 27/11/2019 23:19, Rémy Maucherat wrote:
> 
> 
> 
> > Well, it sounds pretty good to me but the numbers are off and it's
> going
> > to be very very confusing. It pretty much has to be:
> > Tomcat X supporting Jakarta EE X
> > Tomcat X-1 supporting Jakarta EE X-1
> > Tomcat X-2 supporting Jakarta EE X-2
> > And Tomcat 9.X supporting Java EE 8 with the same Tomcat API as
> Tomcat X
> > [I understand the rationale for this to be able to achieve very long
> > term support - and I expect the API changes will likely be rather
> small
> > anyway -, for example 8.5 and 9.0 have diverged too much to keep 8.5
> > more stable, while if we had a 8.6 "trunk" to simply replace it
> > eventually we could have kept in strict sync with 9.0]
> 
> I like it.
> 
> > The only problem then (but it's a big one) is to accommodate the
> Tomcat
> > "10" supporting Jakarta EE 9 somewhere. Maybe 9.9 can be used for that
> > but it will still pollute a bit the 9.x message, it could be
> labelled as
> > a "Jakarta preview" or something maybe. Jakarta EE 9 is a useless
> > release anyway, nobody will use it and that Tomcat could almost be
> EOLed
> > immediately after a Jakarta EE 10 release.
> 
> Hmm. Tricky.
> 
> How about something like this?
> 
> 10.0.0.M1 Jakarta EE 9
> 10.0.0.M2 Jakarta EE 9
> 10.0.0 Jakarta EE 9 stable
> 10.0.1.M1 Jakarta EE 10 dev
> 10.0.1.M2 Jakarta EE 10 dev
> 10.0.1.M3 Jakarta EE 10 dev
> 10.0.1.M4 Jakarta EE 10 dev
> 10.0.1.M5 Jakarta EE 10 dev
> 10.0.0.1 Jakarta EE 9 some urgent bug fix
> 10.0.1.M6 Jakarta EE 10 dev
> 10.0.1.M7 Jakarta EE 10 dev
> 10.0.1.M8 Jakarta EE 10 dev
> 10.0.1    Jakarta EE 10 stable
> ...
> 10.0.n    Jakarta EE 10 stable / Tomcat 10 stable / 10.0.0 is EOL
> 
> 
> Good idea, I like it too. That Jakarta EE 9 is the ultimate transition
> release so it would be fitting if it had the most transitional Tomcat
> branch.
> 
> Are we done already ? That was fast :)

:)

I suspect the US holiday weekend means some folks are still catching up
on email. I have tried to write this down on the wiki:
https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering

I plan to allow a week or so for dev@ comments and refining of the plan
before starting a discussion on users@

I'll also seek feedback from the Spring folks as $work as that
represents a reasonable slice of our Tomcat's user base.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat next and Jakarta EE

[Rémy Maucherat]

On Thu, Nov 28, 2019 at 10:51 AM Mark Thomas  wrote:

> On 27/11/2019 23:19, Rémy Maucherat wrote:
>
> 
>
> > Well, it sounds pretty good to me but the numbers are off and it's going
> > to be very very confusing. It pretty much has to be:
> > Tomcat X supporting Jakarta EE X
> > Tomcat X-1 supporting Jakarta EE X-1
> > Tomcat X-2 supporting Jakarta EE X-2
> > And Tomcat 9.X supporting Java EE 8 with the same Tomcat API as Tomcat X
> > [I understand the rationale for this to be able to achieve very long
> > term support - and I expect the API changes will likely be rather small
> > anyway -, for example 8.5 and 9.0 have diverged too much to keep 8.5
> > more stable, while if we had a 8.6 "trunk" to simply replace it
> > eventually we could have kept in strict sync with 9.0]
>
> I like it.
>
> > The only problem then (but it's a big one) is to accommodate the Tomcat
> > "10" supporting Jakarta EE 9 somewhere. Maybe 9.9 can be used for that
> > but it will still pollute a bit the 9.x message, it could be labelled as
> > a "Jakarta preview" or something maybe. Jakarta EE 9 is a useless
> > release anyway, nobody will use it and that Tomcat could almost be EOLed
> > immediately after a Jakarta EE 10 release.
>
> Hmm. Tricky.
>
> How about something like this?
>
> 10.0.0.M1 Jakarta EE 9
> 10.0.0.M2 Jakarta EE 9
> 10.0.0 Jakarta EE 9 stable
> 10.0.1.M1 Jakarta EE 10 dev
> 10.0.1.M2 Jakarta EE 10 dev
> 10.0.1.M3 Jakarta EE 10 dev
> 10.0.1.M4 Jakarta EE 10 dev
> 10.0.1.M5 Jakarta EE 10 dev
> 10.0.0.1 Jakarta EE 9 some urgent bug fix
> 10.0.1.M6 Jakarta EE 10 dev
> 10.0.1.M7 Jakarta EE 10 dev
> 10.0.1.M8 Jakarta EE 10 dev
> 10.0.1Jakarta EE 10 stable
> ...
> 10.0.nJakarta EE 10 stable / Tomcat 10 stable / 10.0.0 is EOL
>

Good idea, I like it too. That Jakarta EE 9 is the ultimate transition
release so it would be fitting if it had the most transitional Tomcat
branch.

Are we done already ? That was fast :)

Rémy

Re: Tomcat next and Jakarta EE

[Mark Thomas]

On 27/11/2019 23:19, Rémy Maucherat wrote:



> Well, it sounds pretty good to me but the numbers are off and it's going
> to be very very confusing. It pretty much has to be:
> Tomcat X supporting Jakarta EE X
> Tomcat X-1 supporting Jakarta EE X-1
> Tomcat X-2 supporting Jakarta EE X-2
> And Tomcat 9.X supporting Java EE 8 with the same Tomcat API as Tomcat X
> [I understand the rationale for this to be able to achieve very long
> term support - and I expect the API changes will likely be rather small
> anyway -, for example 8.5 and 9.0 have diverged too much to keep 8.5
> more stable, while if we had a 8.6 "trunk" to simply replace it
> eventually we could have kept in strict sync with 9.0]

I like it.

> The only problem then (but it's a big one) is to accommodate the Tomcat
> "10" supporting Jakarta EE 9 somewhere. Maybe 9.9 can be used for that
> but it will still pollute a bit the 9.x message, it could be labelled as
> a "Jakarta preview" or something maybe. Jakarta EE 9 is a useless
> release anyway, nobody will use it and that Tomcat could almost be EOLed
> immediately after a Jakarta EE 10 release.

Hmm. Tricky.

How about something like this?

10.0.0.M1 Jakarta EE 9
10.0.0.M2 Jakarta EE 9
10.0.0 Jakarta EE 9 stable
10.0.1.M1 Jakarta EE 10 dev
10.0.1.M2 Jakarta EE 10 dev
10.0.1.M3 Jakarta EE 10 dev
10.0.1.M4 Jakarta EE 10 dev
10.0.1.M5 Jakarta EE 10 dev
10.0.0.1 Jakarta EE 9 some urgent bug fix
10.0.1.M6 Jakarta EE 10 dev
10.0.1.M7 Jakarta EE 10 dev
10.0.1.M8 Jakarta EE 10 dev
10.0.1Jakarta EE 10 stable
...
10.0.nJakarta EE 10 stable / Tomcat 10 stable / 10.0.0 is EOL

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat next and Jakarta EE

[Rémy Maucherat]

On Wed, Nov 27, 2019 at 11:15 PM Mark Thomas  wrote:

> Hi,
>
> Work over at Eclipse is starting on Jakarta EE 9 where the significant
> change will be the renaming of javax.* to jakarta.*
>
> In parallel, I'd like to start implementing those changes in Tomcat. As
> I am still unsure of exactly where I want end up (I have a few ideas I
> want to experiment with) I plan to do this in a branch of my public fork
> and provide a PR for master when I have a firmer idea of what this will
> look like.
>
> In the meantime, I think we need to start discussing - at least in
> outline - how we will support Java EE and Jakarta EE going forward.
>
> Here is a not very well thought out starter.
>
> Current status
>  7.0.x : Continues to support Java EE 6
>  8.5.x : Continues to support Java EE 7
>  9.0.x : Continues to support Java EE 8
>
> Step 1 (ASAP)
> =
> No change:
>  7.0.x : Continues to support Java EE 6
>  8.5.x : Continues to support Java EE 7
>  9.0.x : Continues to support Java EE 8
> Add:
>  9.5.x : Supports Java EE 8 with Tomcat API changes planned for 10.0.x
>  Make clear to users 9.5.x will EOL as soon as 9.6.x (see later)
>  is stable
>
> Step 2 (Jakarta EE 9 - April 2020?)
> ===
> Announce EOL:
>  7.0.x : Announce EOL around time of first stable 10.0.x release.
> No change:
>  8.5.x : Continues to support Java EE 7
>  9.0.x : Continues to support Java EE 8
>  9.5.x : Supports Java EE 8 with Tomcat API changes planned for 10.0.x
> Add:
> 10.0.x : Identical to 9.5.x but supports Jakarta EE 9
>
> Keep 10.0.x and 9.5.x in step part from Java EE / Jakarta EE API
>
>
> Step 3 (Jakarta EE 10)
> ==
> Announce EOL:
>  8.5.x : Announce EOL around time of first stable 11.0.x release.
>  9.5.x : Announce immediate EOL with first stable 11.0.x release.
> No change:
>  9.0.x : Continues to support Java EE 8
> 10.0.x : Identical to 9.5.x but supports Jakarta EE 9
> Add
>  9.6.x : Supports Java EE 8 and includes Tomcat API changes in 11.0.x
> 11.0.x : Supports Jakarta EE 10
>
> And so on.
>
> We eventually end up with:
> Tomcat X supporting Jakarta EE X-1
> Tomcat X-1 supporting Jakarta EE X-2
> Tomcat X-2 supporting Jakarta EE X-3
> And Tomcat 9.Y supporting Java EE 8 with the same Tomcat API as Tomcat X
>
>
> What I am trying to do with this plan is maintain the 3 major versions
> in parallel but add ongoing support for Java EE 8 tied to the latest
> Tomcat major release.
>
> An alternative would be to maintain 9.0.x for as long as there is demand.
>
> Thoughts? Alternative approaches?
>

Well, it sounds pretty good to me but the numbers are off and it's going to
be very very confusing. It pretty much has to be:
Tomcat X supporting Jakarta EE X
Tomcat X-1 supporting Jakarta EE X-1
Tomcat X-2 supporting Jakarta EE X-2
And Tomcat 9.X supporting Java EE 8 with the same Tomcat API as Tomcat X [I
understand the rationale for this to be able to achieve very long term
support - and I expect the API changes will likely be rather small anyway
-, for example 8.5 and 9.0 have diverged too much to keep 8.5 more stable,
while if we had a 8.6 "trunk" to simply replace it eventually we could have
kept in strict sync with 9.0]

The only problem then (but it's a big one) is to accommodate the Tomcat
"10" supporting Jakarta EE 9 somewhere. Maybe 9.9 can be used for that but
it will still pollute a bit the 9.x message, it could be labelled as a
"Jakarta preview" or something maybe. Jakarta EE 9 is a useless release
anyway, nobody will use it and that Tomcat could almost be EOLed
immediately after a Jakarta EE 10 release.

Rémy

Tomcat next and Jakarta EE

[Mark Thomas]

Hi,

Work over at Eclipse is starting on Jakarta EE 9 where the significant
change will be the renaming of javax.* to jakarta.*

In parallel, I'd like to start implementing those changes in Tomcat. As
I am still unsure of exactly where I want end up (I have a few ideas I
want to experiment with) I plan to do this in a branch of my public fork
and provide a PR for master when I have a firmer idea of what this will
look like.

In the meantime, I think we need to start discussing - at least in
outline - how we will support Java EE and Jakarta EE going forward.

Here is a not very well thought out starter.

Current status
 7.0.x : Continues to support Java EE 6
 8.5.x : Continues to support Java EE 7
 9.0.x : Continues to support Java EE 8

Step 1 (ASAP)
=
No change:
 7.0.x : Continues to support Java EE 6
 8.5.x : Continues to support Java EE 7
 9.0.x : Continues to support Java EE 8
Add:
 9.5.x : Supports Java EE 8 with Tomcat API changes planned for 10.0.x
 Make clear to users 9.5.x will EOL as soon as 9.6.x (see later)
 is stable

Step 2 (Jakarta EE 9 - April 2020?)
===
Announce EOL:
 7.0.x : Announce EOL around time of first stable 10.0.x release.
No change:
 8.5.x : Continues to support Java EE 7
 9.0.x : Continues to support Java EE 8
 9.5.x : Supports Java EE 8 with Tomcat API changes planned for 10.0.x
Add:
10.0.x : Identical to 9.5.x but supports Jakarta EE 9

Keep 10.0.x and 9.5.x in step part from Java EE / Jakarta EE API


Step 3 (Jakarta EE 10)
==
Announce EOL:
 8.5.x : Announce EOL around time of first stable 11.0.x release.
 9.5.x : Announce immediate EOL with first stable 11.0.x release.
No change:
 9.0.x : Continues to support Java EE 8
10.0.x : Identical to 9.5.x but supports Jakarta EE 9
Add
 9.6.x : Supports Java EE 8 and includes Tomcat API changes in 11.0.x
11.0.x : Supports Jakarta EE 10

And so on.

We eventually end up with:
Tomcat X supporting Jakarta EE X-1
Tomcat X-1 supporting Jakarta EE X-2
Tomcat X-2 supporting Jakarta EE X-3
And Tomcat 9.Y supporting Java EE 8 with the same Tomcat API as Tomcat X


What I am trying to do with this plan is maintain the 3 major versions
in parallel but add ongoing support for Java EE 8 tied to the latest
Tomcat major release.

An alternative would be to maintain 9.0.x for as long as there is demand.

Thoughts? Alternative approaches?

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org