commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <>
Subject Re: [collections] beta release - howto
Date Mon, 29 Apr 2013 18:40:55 GMT
On 04/29/2013 04:51 PM, 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.

thanks Phil, I couldn't have summarized it better.

I think we should make the release process easier, and aim for more
alpha/beta releases, I am sure the community and the involved developers
will benefit from it, imho.


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

View raw message