On 4/4/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
If there have been changes since the release was cut, a new release
must IMHO be created, so that people can vote (on the wicket lists
first, and then come back here) on the correct one.
Like Gwyn said, we'd rather wait until *all* feedback is delivered,
before starting a spam action on this list to get the release vetted.
If we need to build, test and upload a new release for each
discrepancy found then the process needs fixing.
Given the lack of time of one of the most trustworthy IPMC members,
this checking takes longer than expected, but we are willing to wait
(not too long, mind you) until we get more feedback.
Also, I'm not too convinced of the "release that is not meant for
public consumption" thing - according to the ASF's definition,
binaries do not constitute a release unless they're meant for public
consumption.
This is not what (most) of the mentors and IPMC members here have
voiced in the past. In order to graduate, a podling is required to
build a release, if only it is a developer only release (take the
harmony podling as an example).
We think that our community is ready for graduation, but we still miss
a release (some of our mentors are pushing for this as well). We think
that building a 'developer'/'legal' release, independent of the
stability of the API (not the code, our unittests run 100% in this
release) and getting the approval from a legal standpoint, will
provide the evidence that the Wicket community is ready to graduate.
The code base is currently in flux (for the reasons given in answer to
Nicklas here on the list), and therefore not ready for consumption by
the general public. Also, the whole idea of the Incubator is to
withhold releases from the general public. This standpoint has just
been under discussion. In this case *the wicket community* chooses not
to release to the general public because the forthcoming changes will
ensure that users have to upgrade their projects once more. We
My suggestions (unless I missed something): create a new release with
clean license headers (i.e. fixes that have already been applied
IIUC), and make it available to the general public, with suitable
disclaimers ("it's veryvery alpha, APIs will change, etc."). If the
disclaimers are scary enough, nobody will use it anyway, but the
process will at least be realistic.
What do you need for it to be realistic other then the process we
already have followed? How does giving it to the general public with
warnings, labels, etc. make the release, or the process of building
the release more real?
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
