I would just call it Tapestry 6.x. It's not going to be compatible with any
previous version, or even with previous servlet containers. I well know the
history ("there will never be Tapesty 6") but past is past, there's no good
reason to avoid a new major, semantic version to indicate the difference.My two cents, Kalle On Thu, Aug 1, 2024 at 1:06 AM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, Tapestry community! > > As already discussed, the Jakarta EE an javax.servlet versions of the > Servlet API have some differences that go beyond the package rename, but, > at the same time, the Tapestry team won't leave the javax.servlet users > behind. We'll have 2 different branches, master on Jakarta EE) and javax, > and we'll keep them in feature parity as much as possible (of course, > Jakarta EE is the living API, while javax.servlet is dead, so any future > Tapestry feature that depends on something Jakarta EE has but javax.servlet > doesn't won't be backported to the javax branch). > > With the approach decided, we arrive at a problem similar to what same say > is the most difficult one in software development: naming things. Current > Tapestry is at version 5.8.6. What should be the version number for the > upcoming Jakarta EE-supporting version? I'd like to remind everyone that > the project itself is Tapestry 5, given it's a complete rewrite that shares > no code with Tapestry 4 and other previous versions, so, for example, > version 5.8.6 should actually be considered version 8.6 of Tapestry 5. > > The Tapestry team has come up with some suggestions: > > * 5.50: Pros: 50 is a round number, half of 100, a lot larger than 8, so we > have a lot of room for new Tapestry major releases of the javax branch to > be 5.9.x, 5.10.x, etc. Con: no easy association between javax and Jakarta > version. > > * 5.19: Pros: 9 is the Jakarta EE version containing the Servlet API > version with the jakarta.servlet package used by Tapestry in the branch > that supports it. While it doesn't leave as much room for new major > releases of the javax branch, it does leave a good number. Con: no easy > association between javax and Jakarta version. > > * 5.18: Pro: easy association between versions of javax and Jakarta > branches, which would be kept in a constant version difference. We could > even have the first Jakarta release to be 5.18.7 while the javax release > would be 5.8.7 (we're planning to release it in the upcoming weeks). Con: > less room for major releases. > > * 5.28: Mostly same as above, but with larger room for major releases. > > * 5.9: Pro: matches the Jakarta EE version. Cons: no room for major > releases at all. (Me, Thiago, really dislike this idea, but another > committer suggested it and really loves it, so here it is, hehehe). > > * Something else you suggest (with rationale, please). > > There's no perfect solution. All of them come with a bit of confusion. I > personally would go with either 5.18 or 5.28 and have the first release > being 5.18.7 or 5.28.7 to align with the upcoming 5.8.7 release. > > I'm looking forward to your feedback. > > Cheers! > > -- > Thiago H. de Paula Figueiredo >
