Re: [collections] beta release - howto

[Jochen Wiedmann <jo...@gmail.com>]

Thanks for bringing me into context, Phil. Of course, I agree with all your
points.

Jochen



On Mon, Apr 29, 2013 at 4:51 PM, Phil Steitz <ph...@gmail.com> wrote:

> On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
> > On Mon, Apr 29, 2013 at 11:02 AM, sebb <se...@gmail.com> wrote:
> >
> >> On 29 April 2013 09:42, Thomas Neidhart <th...@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.
>
> Phil
>
> >
> > Jochen
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
"That's what prayers are ... it's frightened people trying to make friends
with the bully!"

Terry Pratchett. The Last Hero