On Wed, Aug 7, 2024 at 3:40 PM Dmitry Gusev <dmitry.gu...@gmail.com> wrote:
> Hi Thiago, > Hello, Dmitry! > Just a thought, but did you consider to have a `jakarta` word somewhere in > the artifact coordinates? > Actually, I did! I'm happy to know I'm not the only one! :) Not 100% the same idea. I've even started working on it on a branch: https://github.com/apache/tapestry-5/commit/f253bc35fa0b201721b13bee5898b69ca17e6edc I love the Tapestry community. So many smart and clever people. That's one of the main reasons I've started the thread in the first place. The other is being democratic and not just having the committer team deliver an already taken decision with such an impact. The difference between my idea and yours is that I thought about doing the artifact coordinate change for the javax branch, not the jakarta one. I'm open to both options. And I'm starting to think yours is better than mine. Yours doesn't introduce a breaking change for people who continue using the javax branch, which I guess is the majority right now. The jakarta branch would be opt-in. Maybe we should have another poll about which branch should get the classifier or artifact name branch? > Either in the artifact names or as a classifier in the versions. Classifier would be the most elegant solution, I believe, but I couldn't find a way of getting Gradle to generate Maven pom.xml files with them yet. On the other hand, with the work I've done on the commit above we may be able to do that. The missing part is using Gradle's hook for changing the generated pom.xml (the withXml block/call/Groovy closure) to do the coordinate change, either by changing the artifact name or introducing a classifier. We'll also need to adjust the generated dependencies accordingly. The part already implemented is preventing the generation of artifacts of unaffected Tapestry subprojects, such as Plastic and Tapestry-IoC. > This way > we could still have release numbers continue naturally and let the users > pick the flavor. Indeed. > We can eventually stop producing non-jakarta flavors when > time comes, if ever, or do javax/jakarta-only fixes if necessary skipping > the flavors where it would make sense. > Yes. I'd probably try to keep the 2 branches' versions in sync, though. I think branch-specific releases will not be common, at least not in the near future. In addition, with the plan of not having a plastic-javax, tapestry-ioc javax, skipping a version of one branch wouldn't work. > Having holes (regardless how big or small they are) in version numbers will > break semver and tooling that rely on its conventions potentially. > Great point! Thanks for your great feedback! > > > Regards, > Dmitry > > > On Wednesday, July 31, 2024, 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 > > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- Thiago H. de Paula Figueiredo
