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 >> > >> > >> >
