commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: [LANG] Thoughts about Lang 4.0
Date Tue, 23 May 2017 15:22:27 GMT
Tying versions of commons-lang to releases of Java itself makes a bit of
sense to me, but then I do foresee projects containing like 5 different
versions of commons-lang in the future which is somewhat annoying.

On 23 May 2017 at 10:07, sebb <sebbaz@gmail.com> wrote:

> On 23 May 2017 at 12:18, Stephen Colebourne <scolebourne@joda.org> wrote:
> > On 23 May 2017 at 11:54, sebb <sebbaz@gmail.com> wrote:
> >>> Fixing it properly requires a major release, which implies that Lang
> >>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
> >>> package name.
> >>
> >> I think that depends on whether the API is backwards-compatible or not.
> >>
> >> If it *is* backwards-compatible, then do we need a major release?
> >>
> >> If *not*, then 4.0 needs a new package.
> >>
> >> Why?
> >>
> >> Suppose code A depends on a LANG 3 method not present in 4
> >> and code B depends on some new feature in LANG 4
> >>
> >> It's not possible to use A and B together on the same classpath.
> >>
> >> In which case 4.0 must use a new package and Maven coordinates.
> >
> > The change to remove PropertyChangeListener will be incompatible.
> > Thus, if you want to be strict then you have to have a new package and
> > maven co-ordinates. But IMO, this would simply cause end-user projects
> > to have v2.x, v3.x and v4.x on the classpath - its bad enough with two
> > versions right now, I don't personally think removing these two
> > methods is enough to justify a new package/maven co-ordinate and the
> > downstream mess that ensues.
>
> Huh?
>
> The whole point of changing the package name and Maven coords is to
> allow mutually incompatible jars to coexist peacefully on a single
> classpath.
>
>
> > I will note that the JDK is removing methods due to exactly the same
> > issue - modular Java is quite disruptive..
>
> All the more reason not to cause additional unnecessary problems.
>
> > Options that leave the methods in:
> >
> > 1) Add module-info for v3.x that "requires java.desktop" and accept
> > that end-users get Swing/AWT
>
> OK
>
> > 2) Add module-info for v3.x that "requires static java.desktop" (an
> > optional dependency) and accept that users of circuit breaker must
> > manually "require java.desktop".
>
> OK
>
> > Options that remove the methods:
> >
> > 3) Make a backwards incompatible change to remove the bad methods in
> > v3.7 (no package name change)
>
> -1
>
> This is a recipe for jar hell.
>
> > 4) Make a backwards incompatible change to remove the bad methods in
> > v4.0 (no package name change)
>
> -1
>
> This is a recipe for jar hell.
>
> >
> > 5) Make a backwards incompatible change to remove the bad methods in
> > v4.0 (with package name change)
>
> OK
>
> > If you do #4 or #5, you also need #1 or #2 for the v3.x branch. #3 is
> > aggressive but gets rid of the issue in the fastest way.
> >
> > Stephen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message