Hello, Kall, Carlos and Bob!
I appreciate and respect your suggestions, but I'm afraid going to Tapestry
6 is not happening. We already had a bunch of classes moved from one
package to another or even to new packages and we just went to 5.6 to 5.7.
The framework name is Tapestry 5. It's even in the Git repository name:
https://github.com/apache/tapestry-5. I know the past is in the past, but
yet we cannot ignore it. Almost all really major version changes (i.e. 3 to
4, 4 to 5) were either backward-incompatible or, in the 4 to 5 case, a 100%
new codebase. That's not what's happening with the jakarta.servlet issue at
all. We're not breaking backward compatibility with code that uses Tapestry
5.7+ at all (other dependencies like Spring are a different beast, with
maybe some little exception caused by the Servlet API upgrade from 3 to 4.
We've promised in the past that there wouldn't be a Tapestry 6. I think we
should keep our promises.
Cheers!
On Thu, Aug 1, 2024 at 5:37 AM Kalle Korhonen <kalle.o.korho...@gmail.com>
wrote:
> 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
> >
>
--
Thiago H. de Paula Figueiredo
