You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Josh Elser <el...@apache.org> on 2016/05/04 05:43:54 UTC
[VFS] WIP specific release instructions
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
---
# 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}
# Set back to 1.7 because my 1.6 installation has trouble deploying to nexus
$ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
$ 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
--
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
--
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.
* `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)
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
Re: [VFS] WIP specific release instructions
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <se...@gmail.com> wrote:
>
> On 5 May 2016 at 17:08, Ralph Goers <ralph.goers@dslextreme.com <ma...@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 <ma...@gmail.com>> wrote:
>>>
>>> On 5 May 2016 at 13:29, Benedikt Ritter <britter@apache.org <ma...@apache.org> <mailto:britter@apache.org <ma...@apache.org>>> wrote:
>>>> sebb <se...@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
>>>>
>>>>> On 5 May 2016 at 12:22, <ec...@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 <el...@apache.org>
>>>>>> To: Commons Developers List <de...@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<el...@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 <ma...@commons.apache.org> <mailto:dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>>
>>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org> <mailto:dev-help@commons.apache.org <ma...@commons.apache.org>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [VFS] WIP specific release instructions
Posted by Josh Elser <el...@apache.org>.
sebb wrote:
> On 5 May 2016 at 17:08, Ralph Goers<ra...@dslextreme.com> wrote:
>> > I really don\u2019t 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.
>
Yeah, it's ultimately so that I avoid having to constantly revert
commits that I make as go (that release:perform would do). Makes me
appreciate some more of the semantics of Git (but ignore that I said
that before I spur a real religious debate ;))
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] WIP specific release instructions
Posted by sebb <se...@gmail.com>.
On 5 May 2016 at 17:08, Ralph Goers <ra...@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 <se...@gmail.com> wrote:
>>
>> On 5 May 2016 at 13:29, Benedikt Ritter <britter@apache.org <ma...@apache.org>> wrote:
>>> sebb <se...@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
>>>
>>>> On 5 May 2016 at 12:22, <ec...@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 <el...@apache.org>
>>>>> To: Commons Developers List <de...@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<el...@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 <ma...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] WIP specific release instructions
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <se...@gmail.com> wrote:
>
> On 5 May 2016 at 13:29, Benedikt Ritter <britter@apache.org <ma...@apache.org>> wrote:
>> sebb <se...@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
>>
>>> On 5 May 2016 at 12:22, <ec...@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 <el...@apache.org>
>>>> To: Commons Developers List <de...@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<el...@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 <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [VFS] WIP specific release instructions
Posted by sebb <se...@gmail.com>.
On 5 May 2016 at 13:29, Benedikt Ritter <br...@apache.org> wrote:
> sebb <se...@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
>
>> On 5 May 2016 at 12:22, <ec...@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 <el...@apache.org>
>> > To: Commons Developers List <de...@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<el...@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
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] WIP specific release instructions
Posted by Benedikt Ritter <br...@apache.org>.
sebb <se...@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
> On 5 May 2016 at 12:22, <ec...@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?
>
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-87
>
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > -----Original Message-----
> > From: Josh Elser <el...@apache.org>
> > To: Commons Developers List <de...@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<el...@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
>
>
Re: [VFS] WIP specific release instructions
Posted by sebb <se...@gmail.com>.
On 5 May 2016 at 12:22, <ec...@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.
[1] https://issues.apache.org/jira/browse/COMMONSSITE-87
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> -----Original Message-----
> From: Josh Elser <el...@apache.org>
> To: Commons Developers List <de...@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<el...@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
Re: [VFS] WIP specific release instructions
Posted by ec...@zusammenkunft.net.
Hello,
BTW: I would use "mvn verify" instead of "mvn package" (I am not sure what has changed for CP40)
(And yes the release plugin and the commons procedure for releases is a match in hell ,)
Gruss
Bernd
--
http://bernd.eckenfels.net
-----Original Message-----
From: Josh Elser <el...@apache.org>
To: Commons Developers List <de...@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<el...@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
Re: [VFS] WIP specific release instructions
Posted by Josh Elser <el...@apache.org>.
sebb wrote:
> On 5 May 2016 at 05:49, Josh Elser<el...@apache.org> wrote:
>>
>> 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.
>
> They are brand new, and possibly still needing some tweaks.
> They don't work wit Git.
Gotcha. Makes sense. Thanks for bringing them up.
<snip>
>>>> ---
>>>>
>>>> # 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...
>
> mvn deploy
>
Oh ok. I understand what you meant now. A package is still running,
you're just not explicitly invoking it.
>>>> --
>>>>
>>>> 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.
>>
>
> I see.
>
> I meant I did not see why 'mvn deploy ' would/should create the site.
Ah, ok. (with some steps omitted) The lifecycle phases are: package ->
verify -> install -> site -> deploy. Running a deploy also implies that
the site is built.
>>>> 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.
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] WIP specific release instructions
Posted by Benedikt Ritter <br...@apache.org>.
Hello Josh,
It's really great how much effort you're putting into this release. Thank
you for that!
Benedikt
sebb <se...@gmail.com> schrieb am Do., 5. Mai 2016 um 09:57 Uhr:
> On 5 May 2016 at 05:49, Josh Elser <el...@apache.org> wrote:
> >
> >
> > 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.
>
> They are brand new, and possibly still needing some tweaks.
> They don't work wit Git.
>
> >> On 4 May 2016 at 04:43, Josh Elser<el...@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.
>
> OK
>
> > 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.
>
> I agree.
> It's just wrong that trunk is updated before the release succeeds.
> However using a temporary branch would solve that.
>
> > 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...
>
> mvn deploy
>
> >>
> >>> # 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.
>
> They are very new.
>
> >>> --
> >>>
> >>> 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.
>
> They did not exist then...
>
> >>
> >>> --
> >>>
> >>> 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.
> >
>
> I see.
>
> I meant I did not see why 'mvn deploy ' would/should create the site.
>
> >>
> >>> 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
>
>
Re: [VFS] WIP specific release instructions
Posted by sebb <se...@gmail.com>.
On 5 May 2016 at 05:49, Josh Elser <el...@apache.org> wrote:
>
>
> 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.
They are brand new, and possibly still needing some tweaks.
They don't work wit Git.
>> On 4 May 2016 at 04:43, Josh Elser<el...@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.
OK
> 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.
I agree.
It's just wrong that trunk is updated before the release succeeds.
However using a temporary branch would solve that.
> 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...
mvn deploy
>>
>>> # 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.
They are very new.
>>> --
>>>
>>> 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.
They did not exist then...
>>
>>> --
>>>
>>> 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.
>
I see.
I meant I did not see why 'mvn deploy ' would/should create the site.
>>
>>> 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
Re: [VFS] WIP specific release instructions
Posted by Josh Elser <el...@apache.org>.
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<el...@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
Re: [VFS] WIP specific release instructions
Posted by sebb <se...@gmail.com>.
Have a look at the scripts in
http://svn.apache.org/viewvc/commons/scripts/
I used those for VALIDATOR and NET.
On 4 May 2016 at 04:43, Josh Elser <el...@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?
> ---
>
> # 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
> # 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.
> --
>
> 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
> --
>
> 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.
> 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