commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [collections] beta release - howto
Date Mon, 29 Apr 2013 22:01:44 GMT
On Mon, 29 Apr 2013 22:47:15 +0100, sebb wrote:
> On 29 April 2013 21:49, Gilles <> wrote:
>> On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote:
>>> On 29 April 2013 15:51, Phil Steitz <> wrote:
>>>  On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
>>>> > On Mon, Apr 29, 2013 at 11:02 AM, sebb <> wrote:
>>>> >
>>>> >> On 29 April 2013 09:42, Thomas Neidhart 
>>>> <>
>>>> 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.

If someone doesn't develop a Commons component, he is not in the 
category for that component.
If his app _uses_ a Commons component, he is a "user" of that 
This kind of users should indeed be encouraged to test snapshots, and 
problems _before_ an official release is made.

> Regardless, snapshots are not for the general public.

What is the "general public" here?
An application's user (someone who just _runs_ an application that uses 
Commons component) does not belong in the "user" category as intended 


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

View raw message