On 29 April 2013 21:49, Gilles <gil...@harfang.homelinux.org> wrote: > On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote: > >> 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. >> > > ??? > Developers build from source; they don't need the snapshots. > > Not necessarily; they may be developing an app that depends on Commons. Why should they have to additionally set up their system to build a Commons component? Their system might not use Maven.
Regardless, snapshots are not for the general public. > 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. >> > > The main contribution which users can offer is to test snapshots and > provide > feedback on regressions in their applications. > > Regards, > Gilles > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > >
