On Mon, 29 Apr 2013 22:47:15 +0100, sebb wrote:
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.
If someone doesn't develop a Commons component, he is not in the
"developer"
category for that component.
If his app _uses_ a Commons component, he is a "user" of that
component.
This kind of users should indeed be encouraged to test snapshots, and
report
problems _before_ an official release is made.
Regardless, snapshots are not for the general public.
What is the "general public" here?
An application's user (someone who just _runs_ an application that uses
a
Commons component) does not belong in the "user" category as intended
here.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
