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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
