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

Reply via email to