commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [collections] Release 4.0-alpha1 to maven?
Date Fri, 05 Jul 2013 17:19:27 GMT
On 5 July 2013 17:45, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 7/5/13 9:32 AM, Gary Gregory wrote:
>> On Fri, Jul 5, 2013 at 11:33 AM, Phil Steitz <phil.steitz@gmail.com> wrote:
>>
>>> On 7/5/13 7:59 AM, sebb wrote:
>>>> On 5 July 2013 15:47, Phil Steitz <phil.steitz@gmail.com> wrote:
>>>>> On 7/5/13 4:35 AM, Gary Gregory wrote:
>>>>>> Over at log4j we release betas to maven central. I think we should
do
>>>>>> so here too for alphas. It's just too much of a pain to use a jar
in a
>>>>>> build otherwise.
>>>>> Do you subsequently introduce incompatible API changes with no
>>>>> package name change in the "stable" releases?  That's what I would
>>>>> worry about here.  Collections is so widely used / depended on that
>>>>> having API-incompatible versions with the same package name
>>>>> eternally in the wild would seem a bad idea to me.
>>>> Surely API-instability is part of the point of an Alpha release?
>>>>
>>>> Users should be aware that if *they* release anything that depends on
>>>> an Alpha release it may cause breakage in the futiure.
>>> It would be great if we and all downstream users of whatever stuff
>>> ends up shipping with a dependency on a to-be-broken API could
>>> depend on that.  History suggests that you really can't count on
>>> that.   The problem is that it is not just or even primarily the
>>> immediate "users" who get hurt by this.  If it were just the case of
>>> project A direct user of the alpha breaking, I would agree.  For
>>> something like [collections], though, the problem is project A ships
>>> with alpha dependency, gets consumed by B, itself consumed by C, ...
>>> and some poor soul trying to use the actual release in Z get borked
>>> because somewhere along the line the now-abandoned A with
>>> incompatible not package-renamed classes got consumed.
>>>
>> This problem happens already today with normal releases of software, just
>> with behavior changes, not even API breakages.
>>
>> At least with an alpha or beta label we are explicitly warning users.
>>
>> If *you* choose to release with a dependency on an alpha or beta component,
>> then *you* are creating a potential problem.
>>
>> Similarly, if *you* choose to consume a project with direct dependencies on
>> an alpha or beta, that should raise a red flag, and are also possibly
>> creating a problem.
>>
>> The jar hell of transitive dependencies is well know and this does not make
>> it any better or worse.
>
> It *does* make it worse whenever you release incompatible versions
> of the same class.

Only if the dependency is used by another package that is also
generally released, e.g. to Maven Central.

> This is why we agreed to change package names
> when we do that.  We have agreed to make an exception for limited
> distribution alphas / betas.  We should do what we can to limit
> dependency propagation as we get the feedback we are looking for.
> Keeping the artifacts off of maven central will help.  The real
> question is can we get the feedback we need without forever
> advertising these artifacts on maven central.

The issue is not with Maven Central per se.
The same problem can arise with any public release of Alpha code which
is made a dependency of something else that is then released.

> Phil
>>
>> Gary
>>
>>
>>> Phil
>>>> So long as we don't break the API between non-Alpha releases, I don't
>>>> see this as a big issue.
>>>>
>>>> However, we do need to ensure that the non-Alpha release is not left
>>>> too long or people may get impatient and ignore the warnings.
>>>>
>>>>> Phil
>>>>>> Gary
>>>>>>
>>>>>> On Jul 5, 2013, at 4:24, Thomas Neidhart <thomas.neidhart@gmail.com>
>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> just to make sure we have agreement on this topic.
>>>>>>> Reading again the thread about release alpha/beta releases I
think we
>>> did
>>>>>>> not reach consensus whether to publish alpha releases to maven
>>> central.
>>>>>>> It would be easier for people to try out things, but the release
will
>>> stay
>>>>>>> there forever and some people had objections against it.
>>>>>>>
>>>>>>> We also know for sure that the API will change, as we will at
least
>>> rename
>>>>>>> one new class introduced for 4.0 (CompliantBag -> CollectionBag).
>>>>>>>
>>>>>>> So the questions is:
>>>>>>>
>>>>>>> Shall we publish to maven central?
>>>>>>>
>>>>>>> Thomas
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message