I fully agree, but all of this must be clearly defined on the web page. Right now https://maven.apache.org/docs/history.html is not clear about what is and what is not "maintained", and also many plugins still "target" Maven 3.1.1 or 3.2.5, hopefully this proposal along with the "Radical Fast Forward to 3.5.4"[1] will help to lay down the strategy to use.
[1] https://cwiki.apache.org/confluence/display/MAVEN/Baseline+Upgrade+to+Maven+3.5.4 On Mon, Apr 11, 2022 at 12:02 PM Tamás Cservenák <ta...@cservenak.net> wrote: > > Howdy, > > Personally, I'd NOT use the term "supported" at all, as it comes from the > commercial realm (at least for me it sounds like it). > We do not support anything :) > > I'd use the word "maintained" instead. So, according to that: > maven 3.8.x is "maintained ONLY for critical regressions" > maven 3.9.x is coming next out, but more about it later. > maven 4.x is round the corner, and is our main focus (or will be very soon). > Anything else of Maven Core is unmaintained. > Regarding plugins, the very first response we usually do on ML is "did you > try the latest version?". > > But regarding core, Maven major versions 2.x and 3.x were "backward > compatible", the heck, MANY builds today still use plugins having > MAJOR version 2.x, implying they use Maven 2 API: > - m-install-p (2.5.2 released in 2014), > - m-deploy-p (2.8.2 released in 2014) > - m-surefire-p (2.22.2 released in 2019) > etc > > The Maven 2.x -> 3.x transition -- as example shows -- was made with a > major goal set to "ease the transition", > and it worked: Maven core was radically changed (container, resolver, etc), > but surrounding 2.x Mojos kept working as expected. > > OTOH, exactly this "smooth transition" caused a lot of technical issues and > debt, that needs to be addressed, > and will be addressed in Maven 4.x, but this time it will not tackle only > things "behind the curtain", but may > be a bit more jolty for plugins as well, hence for end users. Probably will > require a new 4.x line of plugins as well > (as we tried to introduce a 3.x line of plugins telling they are "aligned" > with maven 3.x). > > The maven-3.9.x branch is technically at a similar level as maven-3.8.x, > but the exact intent is to up its Java level > to Java 8, to make it able to "keep up" with dependencies surrounding it > and pick up the latest features from them, > like new resolver is, etc. The Maven 3.9.x will be "just" a new Maven 3.x > release with great and new (already done > elsewhere) features, but no major Maven feature itself. Once maven-3.9.x is > out, maven-3.8.x becomes "not maintained", > and 3.9.x is "maintained for regressions". > > For new features, we should really focus on Maven 4.x. > > IMHO, just like (hopefully) you do with your OS and IDE, keep it up to > date, I see no reason why someone would > not do the same for their development environment as well. Keep it up to > date. Especially now with the "new" Java > LTS programme, where Java 8 is really OLDEST LTS for many years, but > current LTS Java is 17, and the next LTS > is behind the corner as well (2023?). > > I fully understand developers stuck on Java 5 or 7 or anything pre 8, but > they should understand us as well: > - we have no commercial licenses for those things > - hence, we cannot test against them, even if we would have access to > those, we are OSS project, we have no resources to do that > Nb: same happened in SCM project: commercial SCM systems were dropped, we > cannot maintain something we cannot test. > > So, if for some business reason you are forced to use any pre Java 8 for > development, you have two options: > - use the latest Maven and toolchains targeting old Java > - use the same versions of tools that are from the era when that Java was > latest. Accept that with non-evolved Java your Java toolbox cannot evolve > either. > > My 5 cents > T > > > On Mon, Apr 11, 2022 at 11:25 AM Jorge Solórzano <jor...@gmail.com> wrote: > > > Honestly, the first thing to clarify is, what it means supported/EOL > > in Maven terms?. There is a lot of confusion of what it's supported > > since it's expected that newer versions of Maven should be > > "backward-compatible" with previous versions of Maven. > > > > If I have a project that was "initially" designed for Maven 3.1.1 > > (meaning that the pom works perfectly fine with that version) and then > > I simply upgrade Maven to 3.8.x, the project should "just works"? or > > there is a need to update the pom.xml/plugins, etc too? > > And the reverse should be possible? if I have a project designed for > > 3.8.x, should it work with Maven 3.2.5? At least I know that 3.6.x and > > 3.8.x should be more or less "backward-compatible", but it's hard to > > tell if others are. > > > > Second, supported means that it still receives updates or patches, and > > gets released every now and then, this is not true at all, the last > > version of Maven 3.1.x was 3.1.1 released on 2013-10-04, the other > > name for "supported" of older versions is in "maintenance", that might > > receive critical fixes, yet again this might never happen. In the same > > line, Maven 3.1.x requires Java 5 which is essentially dead since a > > very long time ago, "supporting" Maven 3.1.x is pretty much nonsense. > > (Here I'm talking about Maven core). > > > > Even trying to "support" Maven 3.2.x (3.2.5 released on 2014-12-20) as > > it requires Java 6 is impractical, as Java 6 was EOL 3 years ago (31 > > Dec 2018). In other words if a plugin "claims" to support Maven 3.1.1, > > it should work with Java 5, in any other case it's just "partially" > > compatible and having a table of compatibility is required as it's not > > true that it "supports" Maven 3.1.1. > > > > So, it's hard to define what it means "supported" and "EOL" here, does > > it mean that "plugins" are supported? in other words, that if a new > > plugin is released it should work with Maven 3.1.0? (even if it's hard > > to test on that combination), the CI matrix should test plugins with a > > combo of Java 6, Java 7, Java 8, Java 11 and Java 17, multiplied by > > Maven 3.1.1, Maven 3.2.5, Maven 3.3.9, 3.5.4, 3.6.3, and 3.8.5, which > > I seriously doubt it happen. > > > > In the end, if my project was initially designed for Maven 3.1.1, I do > > not expect that I (or many other users) will just update plugins > > without also testing or updating to newer Maven versions too, so, > > having plugins "supporting" such older versions of Maven is not > > necessarily a good thing, it might make sense if the "supported" > > definition is latest + 2 older versions (3.8.x, 3.6.3, 3.5.4), this if > > we are speaking of plugins, as for Maven itself is still not clear to > > me what it means "supported" as once a new versions is released > > (3.8.x) the older one never get any update (3.6.x). > > > > And yet again, we enter into a new conflict with this definition, if > > Maven 3.9.x requires Java 8 and a lot of plugins are also moving to > > Java 8, then it effectively means that "older" versions will not be > > supported by plugins (in the combination of Java 6 and 7). > > > > Welcome to the pandora box! > > > > On Mon, Apr 11, 2022 at 11:08 AM <herve.bout...@free.fr> wrote: > > > > > > you're focusing on Maven core only > > > I'm talking about Maven = core + plugins > > > > > > and on Maven core, 3.9 and master are for new features, 3.8 is a > > stabilisation branch only (bugfixes) = the intent of initial message from > > Tamas > > > > > > older releases are stable: yes, we don't expect fixes because they are > > considered stable > > > > > > does stable mean EOL? > > > > > > no, because it would mean that we only support unstable versions of > > Maven core > > > > > > ----- Mail original ----- > > > De: "Slawomir Jaranowski" <s.jaranow...@gmail.com> > > > À: "Maven Developers List" <dev@maven.apache.org> > > > Envoyé: Dimanche 10 Avril 2022 21:20:33 > > > Objet: Re: We need to lay down strategy > > > > > > our CI has running build for branches: > > > - master > > > - 3.9.x > > > - 3.8.x > > > > > > It is only versions for which we can do changes, for others we simply > > don't > > > have running infrastructure, so the rest of the versions should be > > > officially mentioned as EOL. > > > > > > To be clear we also should add information what kind of change will be > > > accepted for specific version, like: 3.8.x, 3.9.x only critical > > regression > > > bugs as Tamás mentions > > > > > > niedz., 10 kwi 2022 o 19:59 Hervé BOUTEMY <herve.bout...@free.fr> > > > napisał(a): > > > > > > > Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit : > > > > > Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY: > > > > > > > > > > >> I think that the truth is that versions less than 3.8.x are also > > EOL. > > > > > > > > > > > > no > > > > > > please read the EOL message we took a lot of discussion to define > > for > > > > > > Maven > > > > 3.0.x: > > > > > > "Maven 3.0 has now reached its end of life. New plugin releases > > will > > > > > > require > > > > Maven 3.1 or later." > > > > > > > > > > > > yes, the definition of what "EOL" and "supported" mean for a > > project > > > > like > > > > > > ours > > > > is not so easy: finding the right message is not easy > > > > > > > > > > > > > > > But I don't think that this is the full truth. > > > > > What we actually do is to compile against a specific Maven version, > > but > > > > > only test latest. I don't expect that everyone tests with 3.1.x, > > 3.2.x > > > > > and so it -- I don't and will not. > > > > 1. our CI tests quite a good number of situations: we don't expect > > manual > > > > test > > > > from every committer > > > > 2. even if we don't fully test every detailed situation, we defined our > > > > minimum > > > > required Maven version to show that we support these situation > > > > 3. if you go that route, please define what support means given our OSS > > > > nature > > > > > > > > let's be reasonable at every level > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > -- > > > Sławomir Jaranowski > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
