On Mar 28, 2010, at 1:00 PM, Henri Yandell wrote:
On Sun, Mar 28, 2010 at 10:29 AM, Matt Benson
<gudnabr...@gmail.com> wrote:
On Mar 28, 2010, at 11:29 AM, Henri Yandell wrote:
On Sun, Mar 28, 2010 at 6:40 AM, Matt Benson
<gudnabr...@gmail.com> wrote:
On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote:
Possibly a query for IO too if it's 2.0 has large changes.
Given the large API changes in Lang 3.0 and Collections 4.0, a
beta
release seems like a very useful thing (kudos to pbenedict for
convincing of me that months ago on IM :) ).
I'm interested in what advice and thoughts people might have on
the
subject. Areas I can think of are:
1) versioning, does JIRA identify the version as 3.0-beta1; or
just
have a 3.0 and treat the beta as an invisible release? I'm
preferring
the latter.
2) Maven - does the beta go to the main Maven repo, or just tell
people to pull from snapshot (and make sure there are current
snapshots in the snapshot repo)? I'm thinking the latter.
3) Announcements - blogging, announce@ type announcements
presumably.
4) Length of time spent in beta. I think we should define this
up front.
The intent would be to get early adopters using and finding
bugs, but
more importantly drive conversation around the API changes and
suggest
new ones. I want us to be able to change an API without having
to say
"Yeah, that was dumb - sadly we have to wait 'til 5.0".
I think both Lang and Collections are ready to have a beta release
asap - once some level of documentation is created, both proto
release
documentation and something to define the beta testing period.
Any thoughts are much appreciated,
While we're somewhat on-topic, I would heartily suggest that we
give due
consideration to switching to the Nexus install at
repository.a.o for the
Commons release cycles. This is the way the wind is blowing,
seems to
make
management easier, and is mostly if not completely already set
up as
Ralph
and I have been deploying sandbox snapshots there for some time. A
formal
PMC vote to do all our releases through Nexus would be best,
though we
_could_ continue to do this one component at a time; see
http://issues.apache.org/jira/browse/INFRA-1896.
What would using Nexus change about our release process?
It's pretty well-documented from the JIRA issue I referenced
above. AIUI we
would tweak (or, more likely, de-tweak) some things in our parent POM
hierarchy such that the release cycles of snapshot, RC, and
release would
all be managed through mvn goals. On the whole there should be
much less
manual intervention required for the whole process.
There's a lot of documentation there and let's assume I'm too lazy to
go read a chapter of a book to understand your proposal :)
What was the release process for the sandbox component you and
Ralph released?
To be precise, Ralph and I had worked with Nexus on separate
components, and as those were sandbox components it goes without
saying that they've not been through the entire release process.
We've only published snapshots, and as far as that's concerned, it's
not _that_ huge a difference. I feel that I have had less trouble
publishing snapshots to Nexus than I had to p.a.o, though it's been
so long I honestly can't recall what precisely my problems were--I
have a dim recollection of the whole process going to hell and my
having to manually delete stuff from p.a.o to get things working. I
also mentioned that "this is the way the wind is blowing": it would
appear that the entire ASF is moving toward using repository.a.o and
in this case there's not much point in my trying to sell it,
particularly as I personally am not known to be a big fan of mvn in
general. :P However, I will continue with my stammering attempt to
explain the additional benefits of this change, at risk of failure
due to my admittedly shallow understanding of the whole process. The
primary benefit to the release cycle, as I understand it, is the
support of the staging step. From what I can glean from the
documentation, it would seem that when Nexus is used as the target
repository of a release, a temporary "staging repository" is
generated for your release. You then provide the staging
repository's URL as the basis for the release vote, and, once the
vote is successfully completed, you use the Nexus UI to promote the
entire staging repo to public availability. In particular, the best
soup-to-nuts detail is to be had from http://maven.apache.org/
developers/release/apache-release.html which purports to be a start-
to-finish guide for releasing _any_ Maven-based ASF project. Noting
that our own Commons release instructions have never _seemed_ fully-
baked (and this is meant with no offense to any of the contributors
to said documentation), what's available from the mvn team would
presumably be a step forward to making the release process less
onerous. The referenced URL also mentions things like cutting the
release tag for you, but I am pretty sure this is functionality that
has existed in mvn for quite some time; in fact the details of how to
support the RC-based approach we use @ Commons would be my only
question/concern. As a member of both the Commons and Maven PMCs,
and the other "suspect" in this case, I wonder if Ralph would have
more useful details for us here; Dennis's input would be similarly
welcome.
-Matt
Hen
---------------------------------------------------------------------
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
