On 29 April 2013 15:51, Phil Steitz <phil.ste...@gmail.com> 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. > > Also snapshots must not be advertised to the general public; they are for developer use only. 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.
> Phil > > > > > Jochen > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
