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 20:49:29 GMT
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.

> 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 
feedback on regressions in their applications.


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

View raw message