commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [VFS] WIP specific release instructions
Date Fri, 06 May 2016 06:06:57 GMT
We have never deleted a tag once a vote passed.  Now that tags are immutable we are using rcn
tags and then creating a release tag when the vote passes. But we are still just using the
release plugin.

Ralph

> On May 5, 2016, at 9:49 AM, sebb <sebbaz@gmail.com> wrote:
> 
> On 5 May 2016 at 17:08, Ralph Goers <ralph.goers@dslextreme.com <mailto:ralph.goers@dslextreme.com>>
wrote:
>> I really don’t know why you are making such a big deal about this.
> 
> Because it's important that tags are immutable, and to to a lesser
> degree to avoid creating spurious snapshot builds.
> 
>> I’ve been using the maven release plugin to release Log4j 2 for several years.
That build was created based on the VFS 2.0 release process that also used the maven release
plugin.  As I have said several times, releasing VFS is a lot harder than the rest of Commons
because almost all are single module projects. Log4j 2 has a ton of modules and doesn’t
have any significant problems that can’t easily be dealt with.
> 
> However the Log4j tags have not been immutable.
> 
> Both 2.0.1 and 2.0.2 were updated after initial creation.
> 
> And the 2.0-beta8 tag was created and deleted several times.
> There are other instances of mutable tags.
> 
> This means it may be tricky to demonstrate that the final tag
> corresponds with what was actually voted on.
> 
> It also looks like 2.0 was created from trunk rather than either of the RCs.
> As it happens, that vote passed first time so there was no need to recreate 2.0.
> What would you have done if that vote had failed?
> 
> 
>> The process Josh documented for the 2.release seems a bit more complicated than what
I did for 2.0, but if it works for him, great.
>> 
>> Ralph
>> 
>> 
>>> On May 5, 2016, at 6:41 AM, sebb <sebbaz@gmail.com <mailto:sebbaz@gmail.com>>
wrote:
>>> 
>>> On 5 May 2016 at 13:29, Benedikt Ritter <britter@apache.org <mailto:britter@apache.org>
<mailto:britter@apache.org <mailto:britter@apache.org>>> wrote:
>>>> sebb <sebbaz@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
>>>> 
>>>>> On 5 May 2016 at 12:22,  <ecki@zusammenkunft.net> wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> BTW: I would use "mvn verify" instead of "mvn package" (I am  not
sure
>>>>> what has changed for CP40)
>>>>> 
>>>>> CP40 changed the assembly plugin to run in the verify phase so it can
>>>>> pick up any additional jars added to the package phase by component
>>>>> poms.
>>>>> [It's not possible to ensure the assembly plugin runs at the very end
>>>>> of the assembly phase - see COMMONSSITE-87]
>>>>> 
>>>>> Releases should be generated using
>>>>> 
>>>>> mvn deploy -Prelease
>>>>> 
>>>>> 'mvn package' should still work for generating jars.
>>>>> 
>>>>>> (And yes the release plugin and the commons procedure for releases
is a
>>>>> match in hell ,)
>>>>> 
>>>>> Not just Commons.
>>>>> Any project which allows multiple RCs for the same release is affected.
>>>>> The plugin works best where failed releases are abandoned and the
>>>>> version bumped for the next RC.
>>>>> It does not play well with retries.
>>>>> 
>>>> 
>>>> I wonder how the maven-release-plugin team does this. Don't they run into
>>>> the same problems?
>>>> 
>>> 
>>> The problems I can remember are:
>>> - trunk is unconditionally updated to the next SNAPSHOT version.
>>> This causes problems for components using CI builds (which may not be
>>> the case for them).
>>> 
>>> - if an RC fails, trunk has to be reverted.
>>> Since RC failures are quite common,  the process should be designed accordingly.
>>> Subsequent CI builds will use an earlier SNAPSHOT version, which is confusing.
>>> 
>>> - does it create an immutable tag? I cannot work out from the docs
>>> whether it appends RCn to the tag or not.
>>> If not, then redoing a failed release as the next RC will require
>>> deleting and recreating the tag, or abandoning that release version
>>> and starting again with the next version number.
>>> If it does create an RC tag, what name does it use for the SCM URLs?
>>> 
>>> - the local trunk workspace contains status files which need to be
>>> preseved until the process is complete.
>>> 
>>> 
>>>>> 
>>>>> [1] https://issues.apache.org/jira/browse/COMMONSSITE-87
>>>>> 
>>>>>> Gruss
>>>>>> Bernd
>>>>>> --
>>>>>> http://bernd.eckenfels.net
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Josh Elser <elserj@apache.org>
>>>>>> To: Commons Developers List <dev@commons.apache.org>
>>>>>> Sent: Do., 05 Mai 2016 6:49
>>>>>> Subject: Re: [VFS] WIP specific release instructions
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> sebb wrote:
>>>>>>> Have a look at the scripts in
>>>>>>> 
>>>>>>> http://svn.apache.org/viewvc/commons/scripts/
>>>>>>> 
>>>>>>> I used those for VALIDATOR and NET.
>>>>>> 
>>>>>> Cool. Thanks for sharing. It would be good if the generic commons
>>>>>> release documents referenced these if they are expected to be re-used
by
>>>>>> other commons projects' RMs.
>>>>>> 
>>>>>>> On 4 May 2016 at 04:43, Josh Elser<elserj@apache.org> 
wrote:
>>>>>>>> Here's what I've been doing. The generic instructions are
woefully
>>>>>>>> incomplete (before someone chimes in again - no, not just
because "VFS
>>>>> is a
>>>>>>>> multi-module project"). I think I have this on point for
rc1, so I'm
>>>>> writing
>>>>>>>> it down here before I forget (we can figure out where it
*should* go
>>>>> later).
>>>>>>>> 
>>>>>>>> rc0 only:
>>>>>>>> # Make the branch
>>>>>>>> $ svn cp trunk branches/VFS-XXX
>>>>>>>> $ cd branches/VFS-XXX
>>>>>>>> # Set the proper versions
>>>>>>>> $ mvn release:prepare
>>>>>>> 
>>>>>>> We use a tag not a branch, but perhaps that is what the release
plugin
>>>>> does.
>>>>>>> In which case I assume the branch is taken to avoid mangling
trunk?
>>>>>> 
>>>>>> release:prepare doesn't do the tagging (this is what release:perform
>>>>>> does). All it's really doing are some pre-condition checks and version
>>>>>> updates. TBQH, I don't have any idea how the maven-release-plugin
and
>>>>>> SVN are remotely useful for the ASF's vote-then-promote process.
>>>>>> 
>>>>>> That said, it's ok if I don't get it. This is what worked for me
and I'm
>>>>>> happy with it. If there's something obvious I could have done
>>>>>> differently, great.
>>>>>> 
>>>>>>>> ---
>>>>>>>> 
>>>>>>>> # Or just set it to your JDK6 installation -- this works
on OSX
>>>>>>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
>>>>>>>> 
>>>>>>>> # Where ${asf.username} for me is "elserj"
>>>>>>>> $ mvn clean package -Duser.name=${asf.username}
>>>>>>> 
>>>>>>> No need to use package if using CP40
>>>>>> 
>>>>>> What are you using instead of `package` to build the code...
>>>>>> 
>>>>>>> 
>>>>>>>> # Set back to 1.7 because my 1.6 installation has trouble
deploying to
>>>>> nexus
>>>>>>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
>>>>>>> 
>>>>>>> So does mine; in which case use -Pjava-1.6 below.
>>>>>>> 
>>>>>>>> $ mvn deploy -Prelease -Duser.name=${asf.username}
>>>>>>>> 
>>>>>>>> # This is what could be consolidated via one invocation of
`mvn site`
>>>>>>>> $ mvn site:site site:stage
>>>>>>>> 
>>>>>>>> # Move back to the root SVN repo
>>>>>>>> $ cd ../..
>>>>>>>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN
>>>>>>> 
>>>>>>> Isn't that what the release plugin does?
>>>>>>> 
>>>>>>> You might find
>>>>>>> 
>>>>>>> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh
>>>>>>> 
>>>>>>> easier to use - it does it all for you without needing to create
a
>>>>>>> temporary branch.
>>>>>> 
>>>>>> Cool. I didn't find these from the generic commons release document.
>>>>>> 
>>>>>>>> --
>>>>>>>> 
>>>>>>>> Things not covered above:
>>>>>>>> 
>>>>>>>> * Copying artifacts (tarballs/zips, xsums, and sigs) into
>>>>>>>> dist.a.o/dev/commons/... (building md5/sha1 files)
>>>>>>>> * Closing staging repo in Nexus
>>>>>>> 
>>>>>>> That can be done using Nexus2DistDev.sh
>>>>>> 
>>>>>> Again, great. It would have been good to know about these beforehand.
>>>>>> 
>>>>>>> 
>>>>>>>> --
>>>>>>>> 
>>>>>>>> Some things that could still be improved that I didn't fix:
>>>>>>>> 
>>>>>>>> * Artifacts in dist/target are renamed when they're
>>>>> installed/deployed, but
>>>>>>>> not in the local directory. Should do a rename of the file
on disk so
>>>>> that
>>>>>>>> what is on the RM's computer matches what is in their m2
repo and ASF
>>>>> nexus.
>>>>>>> 
>>>>>>> Or ignore the local copies and use Nexus2DistDev.sh which copies
the
>>>>>>> bin/src artifacts from Nexus and deploys to dist/dev and can
remove
>>>>>>> them from Nexus before closing the staging repo.
>>>>>>> 
>>>>>>> AFAIK only the deploy directory (i.e. Nexus) has the hashes.
>>>>>>> 
>>>>>>>> * `mvn site` which invokes site:site and site:stage automatically
>>>>> (which
>>>>>>>> would make for a more natural build process -- `mvn deploy`
would
>>>>> build the
>>>>>>>> site automatically)
>>>>>>> 
>>>>>>> I don't follow that.
>>>>>> 
>>>>>> `mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site`
>>>>>> and `mvn site:stage` are invoking executions on the maven-site-plugin.
>>>>>> These are two distinct kinds of actions. We can configure the
>>>>>> maven-site-plugin (and/or other necessary tasks) to run at the 'site'
>>>>>> lifecycle phase for a more 'natural' process.
>>>>>> 
>>>>>>> 
>>>>>>>> Again, for now, this is just for my benefit. When this is
all over,
>>>>> I'll try
>>>>>>>> to add this all to the website. Please point out anything
>>>>> wrong/missing.
>>>>>>>> Thanks.
>>>>>>>> 
>>>>>>>> - Josh
>>>>>>>> 
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> 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 <mailto:dev-unsubscribe@commons.apache.org>
<mailto:dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>>
>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>
<mailto:dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message