On Thu, Feb 6, 2020 at 2:31 PM VP Brand <vp-br...@apache.org> 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: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
