> Because I proposed an "intermediate" release with breaking changes. > According to semver, that's a new major version.
The point is really that you should avoid breaking changes, if it doesn't bring significant value for the users. Version changes that might make a weird impression is just a secondary effect. > As for the Maven relocation -- you can just ask on the Maven user mailing list. Group change is low on my list. There are way more urgent issues. So I don't plan to invest more into that. It's just what you said on the PR seems to imply that it's a solved problem, but based on the linked page... honestly, to me it looks as if the problem to solve wasn't well understood. > Anyway, maybe I can get the stuff done in ant, who knows As you know, there's a Gradle PR for a good while. Technically, it's two PR-s, one targtes "3", and another that targets "2.3-gae". The "3" one was already merged (many months ago). To my best knowledge, the "2.3-gae" Gradle it's also working, and it also reproduces what the Ant build does (and without breaking backward compatibility). But because it makes the source code modular (like it is in "3"), therefore merging it would break all other pending PR-s. So, first I have to merge those (those are Java code changes, not build). I plan to do that in December. Then merge a the Gradle PR. Because of this, my intent is that the Jakarta issue (i.e., we need a "jakarta" variant on freemarker.jar, because of the Serlvet API package changes in Jakarta) will also only be solved in Gradle, not in Ant. (If the Gradle merging drags, then still in Ant.) That's my plan, and then members/users can of course stop me, if they don't like it. > but please paste the link to the vote on the mailing into this issue, so we can see that it was agreed on That sounds as if I told you that there was a vote on this issue. There wasn't. I have written a mail to this mailing list back then, that there's this Gradle PR, and please take a look. (Plus, of course members should get an automatic mail on PR-s.) There was no reaction as far as I remember. Surely not an unresolved dispute about it, which would require a vote. (Of course, there will be a vote when we prepare for release on everything included, and no FreeMarker version with Gradle build has been released yet.) On Fri, Nov 3, 2023 at 10:13 PM Benjamin Marwell <bmarw...@apache.org> wrote: > Hi Daniel, > > > FREEMARKER-7 was closed in 2017, with the comment about why (Gradle) > > no, you closed it just as of today. IT was open and unlinked until > Hervé linked it.: > https://issues.apache.org/jira/browse/FREEMARKER-7 -- click the "all" > tab. > > > Also, the version number... Seems to me that you recommend releasing > > something called 3.0.0, which is 2.3.x with the changes you mention. So > > it's major version step up, with no new features users really care > > about, but doing some changes that breaks stuff for some of them. I > mean... > > Why would we do such a thing, I don't get it. > > Because I proposed an "intermediate" release with breaking changes. > According to semver, that's a new major version. > > Anyway, maybe I can get the stuff done in ant, who knows. > > As for the Maven relocation -- you can just ask on the Maven user mailing > list. > Even if you use ant or gradle, package relocation can be explained if > there are any open questions. > > > with the comment about why (Gradle) > > Well I did not see it in the issue as stated earlier, but please paste the > link > to the vote on the mailing into this issue, so we can see that it was > agreed on. > > Thanks! > > - Ben > > Am Do., 2. Nov. 2023 um 19:39 Uhr schrieb Daniel Dekany > <daniel.dek...@gmail.com>: > > > > We can add Jakarta support without any of these (as I noted in that > closed > > PR), I think. We will certainly see in December. If you can solve > something > > in isolation, that's generally a good thing. > > > > Java modules compatibility. Is it not working currently? So every classes > > are are inside the package "freemarker" (I know, I know... very very old > > style). And also we have "Automatic-Module-Name: freemarker" in META-NIF. > > Is that something that is *technically* broken? Or is it just ugly? > > > > FREEMARKER-7 was closed in 2017, with the comment about why (Gradle). You > > say you stumbled into FREEMARKER-7 recently, and started working on your > > PR, which you sent last week. > > > > As of changing group name... only if ordinary users are not affected by > it > > negatively. I did check the Maven relocation guide that you linked, > but... > > I don't get it. Let's say, the user has two transitive dependencies in > its > > application: freemarker:freemarker:2.3.32, and > > org.apache.freemarker:freemaker:2.3.99 (the version number doesn't matter > > now, but note that the group name was modernized between the two > version). > > The switching, where you have published the both a relocation POM with > the > > old group, and also the modernized POM in the new group, happened between > > the two, let's say, at 2.3.80. So in that situation, how will Maven (or > > Gradle, or SBT, etc.) know that these two groups are actually clashing, > and > > they should only keep org.apache.freemarker:freemaker:2.3.99. See, this > > example project has never ever fetched a relocation POM. What am I > missing? > > (Like, replacing all old POM-s with a relocation POM doesn't seem > > practical, as Maven repos meant to be append only basically. Like can I > > replace old POM in maven central? Will corporate Maven repo mirrors > > discover that?) > > > > Dropping support for old stuff... yeah, I want to create a 2.4.0 someday, > > that's a bit(!) more daring in that regard, like we don't support > > outregeously old stuff. But, again, if it only creates problems for > users, > > and it's not a significant deal to drag the old dependencies, then it's > not > > urgent. Like dropping support for non-Jakara is maybe something I would > do > > in a 2.4. But... priorities. Like, java.time support, Java Record > support, > > etc. These are what actually matter for users, and addressing these are > > also stretching forever. (Sorry, sorry... December spring is our next > > hope.) So I would rather invest energy into these kind of things. > > > > Also, the version number... Seems to me that you recommend releasing > > something called 3.0.0, which is 2.3.x with the changes you mention. So > > it's major version step up, with no new features users really care > > about, but doing some changes that breaks stuff for some of them. I > mean... > > Why would we do such a thing, I don't get it. > > > > On Wed, Nov 1, 2023 at 9:06 PM Benjamin Marwell <bmarw...@apache.org> > wrote: > > > > > Hello dev mailing list! > > > > > > Sorry I haven't subscribed earlier. Actually I had, but somehow > > > unsubscribed again. > > > However, I am a user of freemarker for various projects. One of the > > > projects is the Apache Shiro site (via jbake), then my personal blog > > > and a not-so-tiny project at work. > > > > > > However, I recently wanted to contribute back. > > > As a Maven PMC member, I spotted FREEMARKER-7 right away (migrate to > > > maven) and opened PR 96: https://github.com/apache/freemarker/pull/96 > > > However, I learned that there's a "more recent" branch which already > > > got converted to Gradle or at least will be. Then I saw another issue > > > (https://issues.apache.org/jira/browse/FREEMARKER-204) which > > > unfortunately has not been linked to FREEMARKER-7 and the vote on the > > > mailing lists which way to go has not been documented in either of > > > those issues. > > > > > > Anyway, with that gone, I wonder where I could actually contribute. > > > My (personal) dearest which would have been to move the 3-branch to 4 > > > to make room for another "intermedia" 3.0.0 release which only differs > > > from the current 2.x branch by: > > > > > > * Adding an additional jar with jakarta-classifier (maven-terminology) > > > * Maybe move to Java 11 > > > * proper module-info (could also be done on Java 8 if set up properly) > > > * Maybe drop old servlet 2.0 support, along with old JSP to have less > > > duplicated code > > > * Maven, if it helped (but that would probably not be worth it with > > > the project already going to Gradle). > > > * Relocation preparation (from freemarker to org.freemarker or > > > org.apache.freemarker) > > > * Adjusting the module name accordingly. > > > > > > The idea is to ease migration a bit by adding a simpler intermedia > release. > > > > > > I would like to hear from the community what you all would think of > this > > > idea. > > > > > > * No package relocation required > > > * No work for consumers (ie users) > > > * No work for migrating the current 3-branch except renaming the branch > > > > > > Best regards, > > > - Ben > > > > > > > > > -- > > Best regards, > > Daniel Dekany > -- Best regards, Daniel Dekany
