On 4/30/13 7:51 AM, Gilles wrote:
> On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote:
>> On 4/29/13 11:49 PM, Thomas Vandahl wrote:
>>> On 30.04.2013 00:01, Gilles wrote:
>>>> 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.
>>>
>>> I completely agree with you. Looking at the Commons components,
>>> all "users" are also "developers" one way or another, as the
>>> components are merley libraries, not applications.
>>>
>>> From what I understand of the Maven idea, snapshots are *the* way
>>> binaries can be distributed for testing - including separate
>>> storage in a separate repository. The whole repository
>>> infrastructure was made for this. The snapshot status carries the
>>> clear message that this binary is not for production use and can
>>> change its API anytime. So why not use this?
>> The problem with "publicising" snapshots is that it makes it look
>> like they are actual releases. This has been discussed a lot over
>> the years, and we have settled on the policy [1] that anything that
>> we encourage anyone beyond the developers actively following the dev
>> list ("developers" per the definition above), *must* be treated as a
>> release.
>>
>> [1] http://www.apache.org/dev/release.html#what
>
> Thanks for this clarification.
>
> Unfortunately, the description of "release" does not provide a
> solution
> to the problem posed.
> Essentially, it only forbids to ask for user feedback on
> "unreleased" code.
>
> The only way out is to release:
> "If this policy seems inconvenient, then release more often."
>
> But release what? "alpha", "beta"? Those are not defined there.
Projects are free to decide how to name and classify releases as
they see fit. Some projects [1] classify releases as alpha, beta,
stable *after* they have been tested by users. The *requirement* is
just that anything released and "publicised" via web site links,
announcements, etc. must go through the release process, as defined
by the PMC, meeting the minimum ASF requirements [2].
> If such releases are done, then what policy wrt to user support?
Here again, this is up to the PMC to decide. All that the ASF
mandates is that releases are properly vetted by the owning PMC and
meet the minimum requirements.
> E.g. do we _have_ to (quickly) create bug fix releases for such
> releases
> (known to be more fragile)?
>
> This looks much more complicated than just asking interested
> parties to
> "manually" download a nightly build (with all the caveats and
> warnings),
> temporarily add it to their classpath and look for unexpected
> problems.
Should not be, really. We are making good progress - thanks to you
and others - getting to an automated release process. Cutting
alpha/beta releases including votes and compliance checks should not
be that hard and pushing the alpha/beta artifacts to snapshot (and /
or release) maven repos will make it easy for users to test.
Phil
[1] http://tomcat.apache.org/whichversion.html
[2]
http://www.apache.org/dev/release.html#what-must-every-release-contain
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
