commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
Date Tue, 30 Mar 2010 00:47:11 GMT
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 <gudnabrsam@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 <gudnabrsam@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message