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