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 Thu, 05 May 2016 16:08:26 GMT
I really don’t know why you are making such a big deal about this.  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.

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> wrote:
> 
> On 5 May 2016 at 13:29, Benedikt Ritter <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>
> 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