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 <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.
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. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
