[VOTE] Release Apache Tomcat 10.0.0.0-M1

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Release Apache Tomcat 10.0.0.0-M1

Mark Thomas-2
The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
voting. This is the first release of 10.0.0.x and is based on 9.0.31.

The major changes compared to 9.0.31  are:

- Complete the javax to jakarta package rename

- Remove duplication of configuration between HTTP/1.1 and HTTP/2.
  HTTP/2 will now inherit values from HTTP/1.1.

- Remove deprecated code

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0.0-M1/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1244/
The tag is:
https://github.com/apache/tomcat/tree/10.0.0.0-M1
9797ba13e0e554c3b8e990f2dc4f846d2bdccf6d

The proposed 10.0.0.0-M1 release is:
[ ] Broken - do not release
[ ] Alpha  - go ahead and release as 10.0.0.0-M1

I opted to only include alpha here as there are still some potentially
significant changes on the TOMCAT-NEXT list.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

remm
On Wed, Feb 5, 2020 at 8:22 PM Mark Thomas <[hidden email]> wrote:
The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
voting. This is the first release of 10.0.0.x and is based on 9.0.31.

The major changes compared to 9.0.31  are:

- Complete the javax to jakarta package rename

- Remove duplication of configuration between HTTP/1.1 and HTTP/2.
  HTTP/2 will now inherit values from HTTP/1.1.

- Remove deprecated code

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0.0-M1/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1244/
The tag is:
https://github.com/apache/tomcat/tree/10.0.0.0-M1
9797ba13e0e554c3b8e990f2dc4f846d2bdccf6d

The proposed 10.0.0.0-M1 release is:
[ ] Broken - do not release
[X] Alpha  - go ahead and release as 10.0.0.0-M1

I opted to only include alpha here as there are still some potentially
significant changes on the TOMCAT-NEXT list.

Rémy


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Martin Grigorov
In reply to this post by Mark Thomas-2
Hi,

I have a question about https://github.com/apache/tomcat-jakartaee-migration tool: How is it supposed to be used ?
It's README does not explain this.


java -cp target/jakartaee-migration-0.0.2-SNAPSHOT-shaded.jar org.apache.tomcat.jakartaee.Migration ~/devel/apache-tomcat-10.0.0.0-M1/webapps/we.war we.war

but it fails with NPE:

Feb 06, 2020 10:56:35 AM org.apache.tomcat.jakartaee.Migration execute
INFO: Performing migration from source [/home/martin/devel/apache-tomcat-10.0.0.0-M1/webapps/we.war] to destination [/home/martin/git/apache/tomcat-jakartaee-migration/we.war]
Exception in thread "main" java.lang.NullPointerException
at org.apache.tomcat.jakartaee.Migration.execute(Migration.java:87)
at org.apache.tomcat.jakartaee.Migration.main(Migration.java:198)

Martin


On Wed, Feb 5, 2020 at 9:22 PM Mark Thomas <[hidden email]> wrote:
The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
voting. This is the first release of 10.0.0.x and is based on 9.0.31.

The major changes compared to 9.0.31  are:

- Complete the javax to jakarta package rename

- Remove duplication of configuration between HTTP/1.1 and HTTP/2.
  HTTP/2 will now inherit values from HTTP/1.1.

- Remove deprecated code

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0.0-M1/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1244/
The tag is:
https://github.com/apache/tomcat/tree/10.0.0.0-M1
9797ba13e0e554c3b8e990f2dc4f846d2bdccf6d

The proposed 10.0.0.0-M1 release is:
[ ] Broken - do not release
[ ] Alpha  - go ahead and release as 10.0.0.0-M1

I opted to only include alpha here as there are still some potentially
significant changes on the TOMCAT-NEXT list.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Migration tool usage

Mark Thomas-2
On 06/02/2020 08:58, Martin Grigorov wrote:
> Hi,
>
> I have a question
> about https://github.com/apache/tomcat-jakartaee-migration
> <https://github.com/apache/tomcat-jakartaee-migration/blob/master/src/main/scripts/migrate.sh> tool:

I've changed to subject line to reflect this.

> How is it supposed to be used ?
> It's README does not explain this.
>
> I've
> found https://github.com/apache/tomcat-jakartaee-migration/blob/master/src/main/scripts/migrate.sh and
> from it I've figured:
>
> java -cp target/jakartaee-migration-0.0.2-SNAPSHOT-shaded.jar
> org.apache.tomcat.jakartaee.Migration
> ~/devel/apache-tomcat-10.0.0.0-M1/webapps/we.war we.war
>
> but it fails with NPE:

It is expecting a full path to the destination. And you probably want a
different file for the destination as well.

There is lots of scope to improve both the handling and documentation of
input parameters. It is a Tomcat utility rather than a personal project
now so feel free to dive and and improve things.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Migration tool usage

remm
On Thu, Feb 6, 2020 at 10:13 AM Mark Thomas <[hidden email]> wrote:
> but it fails with NPE:

It is expecting a full path to the destination. And you probably want a
different file for the destination as well.

I assumed too much from the getParentFile API, so it's fixed now.
 

There is lots of scope to improve both the handling and documentation of
input parameters. It is a Tomcat utility rather than a personal project
now so feel free to dive and and improve things.

Rémy
Reply | Threaded
Open this post in threaded view
|

Re: Migration tool usage

Martin Grigorov


On Thu, Feb 6, 2020 at 11:24 AM Rémy Maucherat <[hidden email]> wrote:
On Thu, Feb 6, 2020 at 10:13 AM Mark Thomas <[hidden email]> wrote:
> but it fails with NPE:

It is expecting a full path to the destination. And you probably want a
different file for the destination as well.

I assumed too much from the getParentFile API, so it's fixed now.

Thanks!
It is fixed indeed!

Wicket examples are running fine on Tomcat 10!

 

There is lots of scope to improve both the handling and documentation of
input parameters. It is a Tomcat utility rather than a personal project
now so feel free to dive and and improve things.

I will update the README with "Usage".

My destination was different than the source. I was executing the tool from a different folder.
 

Rémy
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Romain Manni-Bucau
In reply to this post by Martin Grigorov
+1 (non binding)

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 6 févr. 2020 à 09:58, Martin Grigorov <[hidden email]> a écrit :
Hi,

I have a question about https://github.com/apache/tomcat-jakartaee-migration tool: How is it supposed to be used ?
It's README does not explain this.


java -cp target/jakartaee-migration-0.0.2-SNAPSHOT-shaded.jar org.apache.tomcat.jakartaee.Migration ~/devel/apache-tomcat-10.0.0.0-M1/webapps/we.war we.war

but it fails with NPE:

Feb 06, 2020 10:56:35 AM org.apache.tomcat.jakartaee.Migration execute
INFO: Performing migration from source [/home/martin/devel/apache-tomcat-10.0.0.0-M1/webapps/we.war] to destination [/home/martin/git/apache/tomcat-jakartaee-migration/we.war]
Exception in thread "main" java.lang.NullPointerException
at org.apache.tomcat.jakartaee.Migration.execute(Migration.java:87)
at org.apache.tomcat.jakartaee.Migration.main(Migration.java:198)

Martin


On Wed, Feb 5, 2020 at 9:22 PM Mark Thomas <[hidden email]> wrote:
The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
voting. This is the first release of 10.0.0.x and is based on 9.0.31.

The major changes compared to 9.0.31  are:

- Complete the javax to jakarta package rename

- Remove duplication of configuration between HTTP/1.1 and HTTP/2.
  HTTP/2 will now inherit values from HTTP/1.1.

- Remove deprecated code

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0.0-M1/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1244/
The tag is:
https://github.com/apache/tomcat/tree/10.0.0.0-M1
9797ba13e0e554c3b8e990f2dc4f846d2bdccf6d

The proposed 10.0.0.0-M1 release is:
[ ] Broken - do not release
[ ] Alpha  - go ahead and release as 10.0.0.0-M1

I opted to only include alpha here as there are still some potentially
significant changes on the TOMCAT-NEXT list.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Martin Grigorov
In reply to this post by Mark Thomas-2


On Wed, Feb 5, 2020 at 9:22 PM Mark Thomas <[hidden email]> wrote:
The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
voting. This is the first release of 10.0.0.x and is based on 9.0.31.

The major changes compared to 9.0.31  are:

- Complete the javax to jakarta package rename

- Remove duplication of configuration between HTTP/1.1 and HTTP/2.
  HTTP/2 will now inherit values from HTTP/1.1.

- Remove deprecated code

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0.0-M1/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1244/
The tag is:
https://github.com/apache/tomcat/tree/10.0.0.0-M1
9797ba13e0e554c3b8e990f2dc4f846d2bdccf6d

The proposed 10.0.0.0-M1 release is:
[ ] Broken - do not release
[ X ] Alpha  - go ahead and release as 10.0.0.0-M1

Tested migrated Apache Wicket examples on both amd64 and arm64 architectures!
 
Regards,
Martin


I opted to only include alpha here as there are still some potentially
significant changes on the TOMCAT-NEXT list.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Konstantin Kolinko
In reply to this post by Mark Thomas-2
ср, 5 февр. 2020 г. в 22:22, Mark Thomas <[hidden email]>:
>
> The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
> voting. This is the first release of 10.0.0.x and is based on 9.0.31.

It is odd to see 4 numbers in "10.0.0.0" instead of the usual 3
"10.0.0", "10.0.x".

Was it intended?

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

remm
On Thu, Feb 6, 2020 at 12:23 PM Konstantin Kolinko <[hidden email]> wrote:
ср, 5 февр. 2020 г. в 22:22, Mark Thomas <[hidden email]>:
>
> The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
> voting. This is the first release of 10.0.0.x and is based on 9.0.31.

It is odd to see 4 numbers in "10.0.0.0" instead of the usual 3
"10.0.0", "10.0.x".

Was it intended?

Yes, it is all explained in the release plan for Jakarta. 10.0.0.x with Jakarta EE 9 will be followed by the "real" release which will be 10.0.1 (then 10.0.2, 10.0.3, etc) with Jakarta EE 10 (with stuff actually new in it).

Rémy
 

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Konstantin Kolinko
чт, 6 февр. 2020 г. в 14:26, Rémy Maucherat <[hidden email]>:

>
> On Thu, Feb 6, 2020 at 12:23 PM Konstantin Kolinko <[hidden email]> wrote:
>>
>> ср, 5 февр. 2020 г. в 22:22, Mark Thomas <[hidden email]>:
>> >
>> > The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
>> > voting. This is the first release of 10.0.0.x and is based on 9.0.31.
>>
>> It is odd to see 4 numbers in "10.0.0.0" instead of the usual 3
>> "10.0.0", "10.0.x".
>>
>> Was it intended?
>
>
> Yes, it is all explained in the release plan for Jakarta. 10.0.0.x with Jakarta EE 9 will be followed by the "real" release which will be 10.0.1 (then 10.0.2, 10.0.3, etc) with Jakarta EE 10 (with stuff actually new in it).

Thank you for your response, but all this is rather confusing.

1). Why cannot we go with the usual 10.0.x for Jakarta EE 9, followed
by 10.0.y for Jakarta EE 10,
e.g. see Specifications page in the wiki like it was for WebSocket 1.0
and WebSocket 1.1 (since 8.0.13),
and maintenance releases of the Servlet specification?

[1] https://cwiki.apache.org/confluence/x/Bi8lBg#Specifications-JavaAPIforWebSocket

2) I hope that somebody will update the following pages:
https://tomcat.apache.org/whichversion.html
https://cwiki.apache.org/confluence/display/TOMCAT/Tomcat+Versions
https://cwiki.apache.org/confluence/display/TOMCAT/Specifications

It is a lot better to stick to the existing numbering scheme (even if
we would skip versions: e,g, Tomcat 10 for Jakarta EE 9 that stays as
"alpha", followed by stable Tomcat 11 for Jakarta EE 10), rather that
to invent a new one.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

remm
On Thu, Feb 6, 2020 at 12:51 PM Konstantin Kolinko <[hidden email]> wrote:
чт, 6 февр. 2020 г. в 14:26, Rémy Maucherat <[hidden email]>:
>
> On Thu, Feb 6, 2020 at 12:23 PM Konstantin Kolinko <[hidden email]> wrote:
>>
>> ср, 5 февр. 2020 г. в 22:22, Mark Thomas <[hidden email]>:
>> >
>> > The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
>> > voting. This is the first release of 10.0.0.x and is based on 9.0.31.
>>
>> It is odd to see 4 numbers in "10.0.0.0" instead of the usual 3
>> "10.0.0", "10.0.x".
>>
>> Was it intended?
>
>
> Yes, it is all explained in the release plan for Jakarta. 10.0.0.x with Jakarta EE 9 will be followed by the "real" release which will be 10.0.1 (then 10.0.2, 10.0.3, etc) with Jakarta EE 10 (with stuff actually new in it).

Thank you for your response, but all this is rather confusing.

1). Why cannot we go with the usual 10.0.x for Jakarta EE 9, followed
by 10.0.y for Jakarta EE 10,
e.g. see Specifications page in the wiki like it was for WebSocket 1.0
and WebSocket 1.1 (since 8.0.13),
and maintenance releases of the Servlet specification?

[1] https://cwiki.apache.org/confluence/x/Bi8lBg#Specifications-JavaAPIforWebSocket

10.0.0.x will not be immediately EOLed I suppose, so that's why there's an extra number.
The plan was discussed and the final version of it is here: https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
 
2) I hope that somebody will update the following pages:
https://tomcat.apache.org/whichversion.html
https://cwiki.apache.org/confluence/display/TOMCAT/Tomcat+Versions
https://cwiki.apache.org/confluence/display/TOMCAT/Specifications

It is a lot better to stick to the existing numbering scheme (even if
we would skip versions: e,g, Tomcat 10 for Jakarta EE 9 that stays as
"alpha", followed by stable Tomcat 11 for Jakarta EE 10), rather that
to invent a new one.

So we decided to invent a new numbering scheme (actually: make a small exception just for this very special release) because this way the EE version matches the Tomcat version number and this is Good. There was a perfected opportunity to do that since Jakarta EE 9 is not a real release (it is only a renamed EE 8) and will only need short term support.

Rémy
 

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Konstantin Kolinko
чт, 6 февр. 2020 г. в 15:06, Rémy Maucherat <[hidden email]>:

>> >> >
>> >> > The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
>> >> > voting. This is the first release of 10.0.0.x and is based on 9.0.31.
>> >>
>> >> It is odd to see 4 numbers in "10.0.0.0" instead of the usual 3
>> >> "10.0.0", "10.0.x".
>> >>
>> >> Was it intended?
>> >
>> >
>> > Yes, it is all explained in the release plan for Jakarta. 10.0.0.x with Jakarta EE 9 will be followed by the "real" release which will be 10.0.1 (then 10.0.2, 10.0.3, etc) with Jakarta EE 10 (with stuff actually new in it).
>>
>> Thank you for your response, but all this is rather confusing.
>>
>> 1). Why cannot we go with the usual 10.0.x for Jakarta EE 9, followed
>> by 10.0.y for Jakarta EE 10,
>> e.g. see Specifications page in the wiki like it was for WebSocket 1.0
>> and WebSocket 1.1 (since 8.0.13),
>> and maintenance releases of the Servlet specification?
>>
>> [1] https://cwiki.apache.org/confluence/x/Bi8lBg#Specifications-JavaAPIforWebSocket
>>
> 10.0.0.x will not be immediately EOLed I suppose, so that's why there's an extra number.

This cannot be achieved with the proposed numbering scheme.

When I think about numbering schemes such as semver, or used for
Maven, or RPM packages, the numbers essentially imply that 10.0.0 and
10.0.1 are binary compatible with only minor changes. When you update
a version of a package, version "10.0.1" will silently supersede
"10.0.0". But that is not the case here.

It is rather hard to explain to people that "10.0.0" is a separate of
branch of development and a separate chain of releases.

> The plan was discussed and the final version of it is here: https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering

The page says "10.0.0.Mx" (in step 1, step 2)


Trying to achieve exact matching between Tomcat version and EE
specification version does not really matter. E.g. Tomcat 9.0 is Java
EE 8, not 9.


Thus far my vote is

The proposed 10.0.0.0-M1 release is:
[x] Broken - do not release

because of the numbering scheme.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

VP Brand
On 06/02/2020 12:36, Konstantin Kolinko wrote:

<snip/>

> This cannot be achieved with the proposed numbering scheme.

Please explain why.

> When I think about numbering schemes such as semver, or used for
> Maven, or RPM packages, the numbers essentially imply that 10.0.0 and
> 10.0.1 are binary compatible with only minor changes. When you update
> a version of a package, version "10.0.1" will silently supersede
> "10.0.0". But that is not the case here.

We are free to define any release numbering scheme we like. Tomcat has
never followed semantic versioning and I don't think it ever will
because of the desire (with the exception of Jakarta EE 9) to have the
major version follow releases of the Servlet spec.

> It is rather hard to explain to people that "10.0.0" is a separate of
> branch of development and a separate chain of releases.

It is simply a special case for Jakarta EE 9 because a) we expect
Jakarta EE 9 to be a transition release and b) it allows us to align
major Tomcat versions with Jakarta EE versions.

>> The plan was discussed and the final version of it is here: https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
>
> The page says "10.0.0.Mx" (in step 1, step 2)

There is a typo. I've fixed it. I've also switched to -Mx for milestones
rather than .Mx for consistency with how Mx is normally used.

> Trying to achieve exact matching between Tomcat version and EE
> specification version does not really matter. E.g. Tomcat 9.0 is Java
> EE 8, not 9.

I think it is useful. It helps reduce confusion if they are aligned.

> Thus far my vote is
>
> The proposed 10.0.0.0-M1 release is:
> [x] Broken - do not release
>
> because of the numbering scheme.

ACK.

Another point to keep in mind is that we expect Jakarta EE 10 to follow
on quickly from Jakarta EE 9. If we were to follow our normal numbering
plan that would mean EOL'ing 7.0.x and 8.5.x in quick succession. I
think that would be bad for our users.

If we didn't EOL 8.5.x that would leave us supporting 8.5.x, 9.0.x,
10.0.x, 11.0.x and 9.11.x - five major versions in parallel compared to
the current three.

The current approach is the best plan the community has come up with to
date that enables us to:
- EOL Jakarta EE 9 support out of sequence
- continue Java EE 8 support in a 9.x branch where X is meaningful
- work on Jakarta EE 10 in parallel with Jakarta EE 9 support

If you have an alternative proposal, now is the time to propose it.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Mark Thomas-2
On 06/02/2020 13:31, VP Brand wrote:

Sorry, selected the wrong sender when composing this reply. Definitely
not sent wearing my VP, Brand hat. This was just me, writing as me.

Mark



> On 06/02/2020 12:36, Konstantin Kolinko wrote:
>
> <snip/>
>
>> This cannot be achieved with the proposed numbering scheme.
>
> Please explain why.
>
>> When I think about numbering schemes such as semver, or used for
>> Maven, or RPM packages, the numbers essentially imply that 10.0.0 and
>> 10.0.1 are binary compatible with only minor changes. When you update
>> a version of a package, version "10.0.1" will silently supersede
>> "10.0.0". But that is not the case here.
>
> We are free to define any release numbering scheme we like. Tomcat has
> never followed semantic versioning and I don't think it ever will
> because of the desire (with the exception of Jakarta EE 9) to have the
> major version follow releases of the Servlet spec.
>
>> It is rather hard to explain to people that "10.0.0" is a separate of
>> branch of development and a separate chain of releases.
>
> It is simply a special case for Jakarta EE 9 because a) we expect
> Jakarta EE 9 to be a transition release and b) it allows us to align
> major Tomcat versions with Jakarta EE versions.
>
>>> The plan was discussed and the final version of it is here: https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
>>
>> The page says "10.0.0.Mx" (in step 1, step 2)
>
> There is a typo. I've fixed it. I've also switched to -Mx for milestones
> rather than .Mx for consistency with how Mx is normally used.
>
>> Trying to achieve exact matching between Tomcat version and EE
>> specification version does not really matter. E.g. Tomcat 9.0 is Java
>> EE 8, not 9.
>
> I think it is useful. It helps reduce confusion if they are aligned.
>
>> Thus far my vote is
>>
>> The proposed 10.0.0.0-M1 release is:
>> [x] Broken - do not release
>>
>> because of the numbering scheme.
>
> ACK.
>
> Another point to keep in mind is that we expect Jakarta EE 10 to follow
> on quickly from Jakarta EE 9. If we were to follow our normal numbering
> plan that would mean EOL'ing 7.0.x and 8.5.x in quick succession. I
> think that would be bad for our users.
>
> If we didn't EOL 8.5.x that would leave us supporting 8.5.x, 9.0.x,
> 10.0.x, 11.0.x and 9.11.x - five major versions in parallel compared to
> the current three.
>
> The current approach is the best plan the community has come up with to
> date that enables us to:
> - EOL Jakarta EE 9 support out of sequence
> - continue Java EE 8 support in a 9.x branch where X is meaningful
> - work on Jakarta EE 10 in parallel with Jakarta EE 9 support
>
> If you have an alternative proposal, now is the time to propose it.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

remm
In reply to this post by VP Brand
On Thu, Feb 6, 2020 at 2:31 PM VP Brand <[hidden email]> wrote:
On 06/02/2020 12:36, Konstantin Kolinko wrote:

<snip/>

> This cannot be achieved with the proposed numbering scheme.

Please explain why.

> When I think about numbering schemes such as semver, or used for
> Maven, or RPM packages, the numbers essentially imply that 10.0.0 and
> 10.0.1 are binary compatible with only minor changes. When you update
> a version of a package, version "10.0.1" will silently supersede
> "10.0.0". But that is not the case here.

We are free to define any release numbering scheme we like. Tomcat has
never followed semantic versioning and I don't think it ever will
because of the desire (with the exception of Jakarta EE 9) to have the
major version follow releases of the Servlet spec.

> It is rather hard to explain to people that "10.0.0" is a separate of
> branch of development and a separate chain of releases.

It is simply a special case for Jakarta EE 9 because a) we expect
Jakarta EE 9 to be a transition release and b) it allows us to align
major Tomcat versions with Jakarta EE versions.

>> The plan was discussed and the final version of it is here: https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
>
> The page says "10.0.0.Mx" (in step 1, step 2)

There is a typo. I've fixed it. I've also switched to -Mx for milestones
rather than .Mx for consistency with how Mx is normally used.

> Trying to achieve exact matching between Tomcat version and EE
> specification version does not really matter. E.g. Tomcat 9.0 is Java
> EE 8, not 9.

I think it is useful. It helps reduce confusion if they are aligned.

> Thus far my vote is
>
> The proposed 10.0.0.0-M1 release is:
> [x] Broken - do not release
>
> because of the numbering scheme.

ACK.

Another point to keep in mind is that we expect Jakarta EE 10 to follow
on quickly from Jakarta EE 9. If we were to follow our normal numbering
plan that would mean EOL'ing 7.0.x and 8.5.x in quick succession. I
think that would be bad for our users.

If we didn't EOL 8.5.x that would leave us supporting 8.5.x, 9.0.x,
10.0.x, 11.0.x and 9.11.x - five major versions in parallel compared to
the current three.

The current approach is the best plan the community has come up with to
date that enables us to:
- EOL Jakarta EE 9 support out of sequence
- continue Java EE 8 support in a 9.x branch where X is meaningful
- work on Jakarta EE 10 in parallel with Jakarta EE 9 support

If you have an alternative proposal, now is the time to propose it.

I agree dedicating the Tomcat 10 branch to Jakarta EE 9 is very bad since it would be EOLed instantly (no actual users and/or no developer interest to support it). Plus I like matching the EE number and the Tomcat branch number.

An option in to do Jakarta EE 9 in 10.0 and Jakarta EE 10 as 10.1. But this normally also implies some support for 10.0, and at the moment the forecast is that there will be none.

Another possible option I can think of is to not release that 10.0.0.0 at all. That means that right now 10.0 is in M mode doing Jakarta EE 9, it will switch to tracking EE 10 when it starts and remains in M mode until EE 10 is final. Developers who want to migrate to Jakarta can still use these M builds even though they are not stable, etc.
I don't really like it and would much prefer if, as a simple exception, people would agree to release that interim 10.0.0.0 ...

Rémy
 

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Martin Grigorov


On Thu, Feb 6, 2020 at 3:58 PM Rémy Maucherat <[hidden email]> wrote:
On Thu, Feb 6, 2020 at 2:31 PM VP Brand <[hidden email]> wrote:
On 06/02/2020 12:36, Konstantin Kolinko wrote:

<snip/>

> This cannot be achieved with the proposed numbering scheme.

Please explain why.

> When I think about numbering schemes such as semver, or used for
> Maven, or RPM packages, the numbers essentially imply that 10.0.0 and
> 10.0.1 are binary compatible with only minor changes. When you update
> a version of a package, version "10.0.1" will silently supersede
> "10.0.0". But that is not the case here.

We are free to define any release numbering scheme we like. Tomcat has
never followed semantic versioning and I don't think it ever will
because of the desire (with the exception of Jakarta EE 9) to have the
major version follow releases of the Servlet spec.

> It is rather hard to explain to people that "10.0.0" is a separate of
> branch of development and a separate chain of releases.

It is simply a special case for Jakarta EE 9 because a) we expect
Jakarta EE 9 to be a transition release and b) it allows us to align
major Tomcat versions with Jakarta EE versions.

>> The plan was discussed and the final version of it is here: https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
>
> The page says "10.0.0.Mx" (in step 1, step 2)

There is a typo. I've fixed it. I've also switched to -Mx for milestones
rather than .Mx for consistency with how Mx is normally used.

> Trying to achieve exact matching between Tomcat version and EE
> specification version does not really matter. E.g. Tomcat 9.0 is Java
> EE 8, not 9.

I think it is useful. It helps reduce confusion if they are aligned.

> Thus far my vote is
>
> The proposed 10.0.0.0-M1 release is:
> [x] Broken - do not release
>
> because of the numbering scheme.

ACK.

Another point to keep in mind is that we expect Jakarta EE 10 to follow
on quickly from Jakarta EE 9. If we were to follow our normal numbering
plan that would mean EOL'ing 7.0.x and 8.5.x in quick succession. I
think that would be bad for our users.

If we didn't EOL 8.5.x that would leave us supporting 8.5.x, 9.0.x,
10.0.x, 11.0.x and 9.11.x - five major versions in parallel compared to
the current three.

The current approach is the best plan the community has come up with to
date that enables us to:
- EOL Jakarta EE 9 support out of sequence
- continue Java EE 8 support in a 9.x branch where X is meaningful
- work on Jakarta EE 10 in parallel with Jakarta EE 9 support

If you have an alternative proposal, now is the time to propose it.

I agree dedicating the Tomcat 10 branch to Jakarta EE 9 is very bad since it would be EOLed instantly (no actual users and/or no developer interest to support it). Plus I like matching the EE number and the Tomcat branch number.

An option in to do Jakarta EE 9 in 10.0 and Jakarta EE 10 as 10.1. But this normally also implies some support for 10.0, and at the moment the forecast is that there will be none.

Another possible option I can think of is to not release that 10.0.0.0 at all. That means that right now 10.0 is in M mode doing Jakarta EE 9, it will switch to tracking EE 10 when it starts and remains in M mode until EE 10 is final. Developers who want to migrate to Jakarta can still use these M builds even though they are not stable, etc.

I think this would be the less confusing schema for the users.
Tomcat 10.0.0-Mx will be for Jakarta EE 9.
Once Jakarta EE 10 is released we can remove the -Mx
 
I don't really like it and would much prefer if, as a simple exception, people would agree to release that interim 10.0.0.0 ...

Rémy
 

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Christopher Schultz-2
In reply to this post by Konstantin Kolinko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Konstantin,

On 2/6/20 7:36 AM, Konstantin Kolinko wrote:
> Thus far my vote is
>
> The proposed 10.0.0.0-M1 release is: [x] Broken - do not release
>
> because of the numbering scheme.

Please remember:

1. The transitional version numbering scheme *is* completely confusing

2. The target version numbering scheme is VERY consistent, and a good
idea IMO

3. The transitional version numbering scheme will be retired ASAP

Please consider changing your -1 release-veto vote.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl48LFgACgkQHPApP6U8
pFhQFRAAjCgSnuyQmJdOE3ZseR/4KJiRNYSUHkUiQLPNOzVmI3RDtOvyOV3eIEsT
E/1zL2v1PL86WmqUlMfVBg6xVr0uiH9Hu3Qtn5a929IvFtnJ3PEmeFveLX1FBMqf
6udf7rhTncH8KH9didDAjWo//U23w1ToiwX7XfC7b7yPrLWlLaKoPPmQPEz8yr9h
BhLeINxWmrhA4iANstUvw/Adz7FSbysgRnE7E5pZb3ceIlb77Cb6o/qFsjxZ8S09
J0cFwXMMfFzISjpNGh6L8pSjmplAufsa3pRuv9+5rEiiPgfQcqdg7mv/zO4+O/iH
rMVo8wm+oPSnnRMj/Eo8p24RIbgu1ypvuRce23jdoD/Q/1vXtW3Oc6aK1GkO3Aqk
drHqsPDYLKl0/o3WgRbiK59U4Idy5/GnlxAdsWwd01Ir7A5utbVQ101220zSpMPZ
6Zg5Nc4tamV0n0b+Ytw9ZsMyxoUXv1lc6Pz88LPRpre0KlMgFJ04xHPYLRqbDvWd
l/mh+g/RDSVBZkY9q9TNbaKFYr5yvovRrxEgKvfs1s/WPcW6RG+0Yvo1AkHLoTHy
bIfNBYnysXFkc0040lXufH2mOjuzU2Ib2opr4/aM7AGLZMzJxpl0WASU1t3CsJs1
qfwgx/hibHNV4hGGY4Hz1CzxZC325E3opPgB74qouVNvudx/+Ek=
=Mgon
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

Mark Thomas-2
On February 6, 2020 3:10:16 PM UTC, Christopher Schultz <[hidden email]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Konstantin,
>
>On 2/6/20 7:36 AM, Konstantin Kolinko wrote:
>> Thus far my vote is
>>
>> The proposed 10.0.0.0-M1 release is: [x] Broken - do not release
>>
>> because of the numbering scheme.
>
>Please remember:
>
>1. The transitional version numbering scheme *is* completely confusing
>
>2. The target version numbering scheme is VERY consistent, and a good
>idea IMO
>
>3. The transitional version numbering scheme will be retired ASAP
>
>Please consider changing your -1 release-veto vote.

For the record, this is not a veto. Release votes may not be vetoed.

As release manager I'm not adverse to a *slight* delay in this release if we appear to be heading towards a modified consensus.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] [OT] Release Apache Tomcat 10.0.0.0-M1

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 2/6/20 10:35 AM, Mark Thomas wrote:

> On February 6, 2020 3:10:16 PM UTC, Christopher Schultz
> <[hidden email]> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Konstantin,
>>
>> On 2/6/20 7:36 AM, Konstantin Kolinko wrote:
>>> Thus far my vote is
>>>
>>> The proposed 10.0.0.0-M1 release is: [x] Broken - do not
>>> release
>>>
>>> because of the numbering scheme.
>>
>> Please remember:
>>
>> 1. The transitional version numbering scheme *is* completely
>> confusing
>>
>> 2. The target version numbering scheme is VERY consistent, and a
>> good idea IMO
>>
>> 3. The transitional version numbering scheme will be retired
>> ASAP
>>
>> Please consider changing your -1 release-veto vote.
>
> For the record, this is not a veto. Release votes may not be
> vetoed.

Fair enough, but generally speaking, any -1s on release-vote are taken
with a lot of weight around here, as you very well know. I'd prefer
not to release in conflict with *any* objections if it's possible.

> As release manager I'm not adverse to a *slight* delay in this
> release if we appear to be heading towards a modified consensus.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl48NLYACgkQHPApP6U8
pFggdg/+Jqi6DsoXqXQdHCR5TrXTlUIJpgUlSwiTRH+ArGxZqb0V4O5Nb9Y1qL8t
4NRY8fcrGy1OEra7YRm9WakBbQ3FXkiq+/cng8NzMYkXDz+8MsXOevgarUdJgr/C
CZF9+xXQ/ZxNec4FO1+KN8ocUVB87irSY/uJ/QSpbifca9VofFwfUh3ITeUBSO8J
FfpyoJCxIhy66MBW/LNIvedkeFbJGVMcxnwn+IIRtXiMWrp68SxnUth68ySWx7l2
lpOH2y5LofgDWWaPE4CQZiOOGI7vEZaIWOJB0RjrcUT4CtFGKBvrrVLuiFlhnqRy
j8fvysNRuSzYVx8PPoL6hB93DnVXZtZxXgdJxFgcZZLaZMP/rWsLswXsr0TDlqKL
EWUA1IBMnbRAJ2FLoqG9cvBirKOCVlIuj9OW9KkGFXVyBZuEk0+A/vGn3UAlSOA+
7NsvydY2sNcuhy+85i6ljnDyIarzD9Wdly3g7egUpMaZaCLce77856Hpx1ExsKY3
6ojyAD/ObtuIjfDVY+XabKwoshJXYEPoZri6HjoaCMpZatpxKP4o7QURd5snV9Dk
msb1vMZ7yAsr8ZMPY3UEJAYRq+HttcSg0kVHdV3pDJtI4dyl/ZCemSupI0VDGv8y
pY+P6TDkurK94a627Qq1FKBNiLo+g3UJdwg9KTMa6JU9xxgTEmQ=
=FFfY
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12