commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <>
Subject Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Date Thu, 10 Oct 2013 14:04:42 GMT
I think the idea is that we don't break BC between an older full
version and a new alpha/milestone/rc/whatever, unless of course, the
new alpha/milestone/rc/whatever release is on a new major version.
For example, we can have API breaks between commons-foo-1.0 and
commons-foo-2.0-alpha.  We can have API breaks between
commons-foo-2.0-alpha1 and commons-foo-2.0-alpha2.  We cannot have API
breaks between commons-foo-2.0 and commons-foo-2.1-alpha.  How does
that sound (the concept not the choice of alpha)?

On Thu, Oct 10, 2013 at 9:47 AM, Gary Gregory <> wrote:
> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
> <> wrote:
>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <> wrote:
>>> I'm afraid this is more than a perceived issue, the plexus-container
>>> example given by Jörg is a very good one. Pushing drastically
>>> incompatible versions to Maven Central is not a good service for the users.
>>> I think my suggestion is a good compromise, otherwise the die-hard
>>> compatibility defenders here will never agree to publish incompatible
>>> artifacts to Maven Central.
>> This gets back to my earlier comments on another thread.  We can't try
>> to stupid-proof our code.  If our users want to do something stupid,
>> we can't protect them from themselves.  If they want to "release" code
>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>> them.
>>> I agree this is annoying, but this has to be balanced with the annoyance
>>> of dealing with incompatible dependencies (for example, components
>>> depending on different versions of BouncyCastle). It's easy to rename an
>>> import in your code compared to fixing a jar hell situation.
>> If a third-party library releases a version which points at one of our
>> alpha releases and relies upon an API that they've been told may not
>> be stable, then they need to fix it.  Again, we can boil the ocean
>> trying to think up all the stupid things people can do with our
>> software and try to code/process around it, but at the end of the day,
>> you can't fix stupid.
> Indeed, developers and users will forever find creative and painful
> ways to shoot themselves in the foot and other appendages.
> Conversely, we should not hand out defective weaponry by breaking
> Binary Compatibility (this relates to a discussion on another thread:
> I claim it is never OK to break BC, you release a new (Java) package
> to do the equivalent).
> Gary
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> E-Mail: |
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog:
> Home:
> Tweet!
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message