Ok, makes sense if we don't re-break the API just after (previous point) otherwise I would skip the removal to do both in next major then.
Just my 2cts indeed. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 25 juil. 2023 à 16:57, Tamás Cservenák <ta...@cservenak.net> a écrit : > meh, auto correct: IS AT THE COST ("not" should be removed). > So in other words, session and some other components will get some > deprecated methods (were deprecated for 2 years) removed. > > T > > On Tue, Jul 25, 2023 at 4:55 PM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > Howdy, > > > > Just a remark, that may not be clear from the thread starter: > > "dropping deprecated baggage" is not at the cost of binary breakage, > hence > > I assumed 2.0 is good to make it clear. > > (binary breakage in form that methods and classes deprecated since > version > > 1.8.0 will be dropped) > > > > T > > > > On Tue, Jul 25, 2023 at 4:49 PM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > >> Nothing strong against, just noting that 2.x does not plan anything > >> requiring to upgrade (1.9.x is fine for the planned changes) so I'd say > >> your 3 can be the 2 and hopefully we can move to a more reactive version > >> (would enable to not set up aether with 128 threads or alike on CI but > >> just > >> 4 and still be faster to download when server supports it) - guess we > >> don't > >> aim at supporting java 21 soon enough to skip it. > >> > >> So my wishlist would be: > >> > >> * 1.9.x while we dont change things much > >> * 2.0.x package relocation and hopefully reactive contract instead of > >> synchronous impl > >> > >> That said more a wish than anything else since "it works" like that too, > >> it > >> is just botherwise in some cases (like when populating a repo from > >> scratch). > >> > >> Romain Manni-Bucau > >> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >> <https://rmannibucau.metawerx.net/> | Old Blog > >> <http://rmannibucau.wordpress.com> | Github < > >> https://github.com/rmannibucau> | > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >> < > >> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >> > > >> > >> > >> Le mar. 25 juil. 2023 à 16:23, Elliotte Rusty Harold < > elh...@ibiblio.org> > >> a > >> écrit : > >> > >> > Tangential note: I dislike multi-digiti minor versions. 1.10 is just > >> > way too easy to confuse with 1.1.0. That is, when one reaches 1.9 it's > >> > time to move to 2.0, even if you don't plan to break the API in any > >> > way. So +1 for moving the next version to 2.0 > >> > > >> > On Thu, Jul 20, 2023 at 6:20 AM Tamás Cservenák <ta...@cservenak.net> > >> > wrote: > >> > > > >> > > Howdy, > >> > > > >> > > I'd like to pitch some discussion regarding Resolver near and longer > >> term > >> > > future. > >> > > > >> > > If you look at the JIRA version "planned for" 1.10.0, there are > quite > >> > some > >> > > (even partially done) code changes that are not trivial. Moreover, > we > >> > want > >> > > to drop some deprecated baggage as well: > >> > > > >> > > >> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.10.0 > >> > > > >> > > My proposal is to move on to Resolver 2.0.0 instead. > >> > > > >> > > So, Resolver wise my proposal is: > >> > > - resolver 1.9.x branched off, goes into "bugfix" mode > >> > > - resolver master goes 2.0.0, with new features (already in JIRA or > >> not > >> > yet) > >> > > - resolver 3.0.0 will also contain java package change > >> > (org.eclipse.aether > >> > > -> org.apache.maven.resolver), so package change becomes "shifted" > >> from > >> > > 2.0.0 to 3.0.0 > >> > > > >> > > Maven wise, this happens: > >> > > - Maven 3.9.x remains on resolver 1.9.x (and will also slowly go > into > >> > > "bugfix" mode) > >> > > - Maven 4.x moves to resolver 2.0.0 (still must support Maven 3 > >> plugins > >> > > going directly for resolver) > >> > > - Maven 5.x moves to resolver 3.0.0 (when the resolver is sealed off > >> > > completely from plugins). > >> > > > >> > > WDYT? > >> > > > >> > > Thanks > >> > > T > >> > > >> > > >> > > >> > -- > >> > Elliotte Rusty Harold > >> > elh...@ibiblio.org > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > >> > > >> > > >