Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 30 Apr 2013 00:01:44 +0200
From: Gilles <gilles@harfang.homelinux.org>
To: <dev@commons.apache.org>
Subject: Re: [collections] beta release - howto
In-Reply-To: 
 <CAOGo0VaFNZ_wSW+N7QdupzL2PcdRhbhi1Scn+EeK6QqnLbsavw@mail.gmail.com>
References: <5178D3D6.3030503@gmail.com>
 <CAF8HOZJEVEq1UDdXptmvgmrVyXV6qSShzD40cNO-PRBde2Km1A@mail.gmail.com>
 <CAPVuaYtZCjpMF8K2UfVhKdK0wkSbACaeqEv7b1ffjJBrLPkZpw@mail.gmail.com>
 <CAOGo0VbN1OoPNEWfq7g-myDzTqd6Bjrv8R4x9Pj_fNtvs2EwEQ@mail.gmail.com>
 <CAJSjvwsvu___hO889KS8M=8nzBZsW7rGQf9P_MdjDuezxzC0kw@mail.gmail.com>
 <CAOGo0VY6C3DFp451n+W2sES6+1UMo1=VmZnsndMj7VuQBZJ0kA@mail.gmail.com>
 <CAF8HOZJ5APS+RiQT6wZQ2-A5wtaUH-ivwzJKz+QYrL-449gcEQ@mail.gmail.com>
 <517E88F6.9060001@gmail.com>
 <CAOGo0VacWCokiPC1PuJfEjkYAH3VWSGi+vyc9VcP6fUnDG+CQQ@mail.gmail.com>
 <7ee93b566fc2edb57eddc488f4afad0c@scarlet.be>
 <CAOGo0VaFNZ_wSW+N7QdupzL2PcdRhbhi1Scn+EeK6QqnLbsavw@mail.gmail.com>
Message-ID: <fb914416cb6aeda9100fdab0cac46703@scarlet.be>
User-Agent: Scarlet Webmail
X-DCC-scarlet.be-Metrics: sif; whitelist
X-Virus-Scanned: clamav-milter 0.97.1-exp at sif
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

On Mon, 29 Apr 2013 22:47:15 +0100, sebb wrote:
> On 29 April 2013 21:49, Gilles <gilles@harfang.homelinux.org> wrote:
>
>> On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote:
>>
>>> On 29 April 2013 15:51, Phil Steitz <phil.steitz@gmail.com> wrote:
>>>
>>>  On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
>>>> > On Mon, Apr 29, 2013 at 11:02 AM, sebb <sebbaz@gmail.com> wrote:
>>>> >
>>>> >> On 29 April 2013 09:42, Thomas Neidhart 
>>>> <thomas.neidhart@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org