Dennis Lundberg wrote: > 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.
Can you go directly to staging - i.e., can we push a completed RC to Nexus as we do to our public_html directories and then promote it from there, or do we have to use the release plugin and pom config to somehow have nexus involved in cutting the rc? Phil > >> -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 >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
