On 2010-03-29 17:11, Matt Benson wrote: > > 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.
In my view the most important gain of using Nexus is the fact that a release will never be accidental. Any attempt to release a component will halt in Nexus, until the RM goes there to promote it. This usually happens after a vote has been held. This will effectively prevent any rogue SNAPSHOT making its way to the Central repository. We do have some safeguards against this in the current Commons parent POM, but they require the use of profiles. We've been using Nexus in the release process for Maven itself for a while now. As with any new system there are a couple of tasks that you need to learn simply because they are new to you. The documentation (as linked to by Matt) is now very good and includes screen shots of the web UI that you use to promote a release. > > -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 > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
