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.
If such releases are done, then what policy wrt to user support?
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.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
