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