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