On Thu, Feb 6, 2020 at 3:58 PM Rémy Maucherat <r...@apache.org> wrote:
> 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 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: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >>
