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