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 <seb...@gmail.com> wrote: > > On 5 May 2016 at 13:29, Benedikt Ritter <brit...@apache.org > <mailto:brit...@apache.org>> wrote: >> sebb <seb...@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr: >> >>> On 5 May 2016 at 12:22, <e...@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 <els...@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<els...@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-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > <mailto:dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > <mailto:dev-h...@commons.apache.org>
