commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [collections] beta release - howto
Date Mon, 29 Apr 2013 21:47:15 GMT
On 29 April 2013 21:49, Gilles <gilles@harfang.homelinux.org> wrote:

> On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote:
>
>> On 29 April 2013 15:51, Phil Steitz <phil.steitz@gmail.com> wrote:
>>
>>  On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
>>> > On Mon, Apr 29, 2013 at 11:02 AM, sebb <sebbaz@gmail.com> wrote:
>>> >
>>> >> On 29 April 2013 09:42, Thomas Neidhart <thomas.neidhart@gmail.com>
>>> wrote:
>>> >>
>>> >>> Well, I certainly *want* to change the API if something is broken,
>>> so I
>>> >>> guess an alpha release would be safer.
>>> > Please keep upwards compatibility to any previous releases in mind.
>>> > Commons' reputation relies heavily on that.
>>>
>>> I agree with this in general, but there are two "special" things
>>> going on here:
>>>
>>> 0) What Thomas is looking to alpha is [collections] 4, which is a
>>> major release that brings in generics, so will not be backward
>>> compatible with previous releases.
>>> 1) Given the amount of API change, we want feedback on the API if we
>>> can get it during an alpha period
>>>
>>> IIRC, we did this for [lang] 3.0, but called in "beta."  I can't
>>> remember how exactly we managed the messaging and publication of
>>> artifacts, but it appears that the beta has now pretty much
>>> vanished.  Maybe Hen can describe how we handled that.  I think that
>>> as long a) we make it clear in release notes and on the web page
>>> that what we are releasing in the alpha may have incompatible API
>>> "fixes" added in the final 4.0 release and b) we get the final out
>>> fairly soon after (maybe a month or two), I don't see a problem with
>>> this.
>>>
>>> Looking back on [math] 3 and forward to [math] 4, I think we would
>>> benefit there as well from the ability to cut alpha releases so we
>>> can fix API bugs during an alpha review period.  It would be great
>>> if we could settle on a way to do this without causing too much pain
>>> for users and Commons developers.  The keys are probably strong
>>> warnings on the alphas, relatively short alpha eval periods and
>>> maybe foregoing pushing alphas to the public maven repos.
>>>
>>> The only alternative to this approach (other than just living with
>>> whatever API mistakes we make until the next major release) is to
>>> "publicize" a snapshot, which I think is a worse option because if
>>> we want users outside of the immediate development community to use
>>> something, we should follow the normal steps to cut an official release.
>>>
>>>
>>>  Also snapshots must not be advertised to the general public; they are
>> for
>> developer use only.
>>
>
> ???
> Developers build from source; they don't need the snapshots.
>
>
Not necessarily; they may be developing an app that depends on Commons.
Why should they have to additionally set up their system to build a Commons
component?
Their system might not use Maven.

Regardless, snapshots are not for the general public.


>  e.g. I think it's OK to mention them in a JIRA so interested parties can
>> test if a bug has been fixed, but not on the user list nor on download
>> pages.
>>
>
> The main contribution which users can offer is to test snapshots and
> provide
> feedback on regressions in their applications.
>
> Regards,
> Gilles
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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