Re: [DISCUSS] Creating Project for Release Process Testing...
>From the time I spent recently perusing their API docs, I would guess from the fact that they qualify the URL scheme with a "1" version, that they will preserve compatibility indefinitely. If they alter their API I presume it will use a different version ID on the URL. Matt On Tue, Oct 15, 2013 at 2:08 PM, sebb wrote: > On 15 October 2013 19:33, Matt Benson wrote: > > Asked on #asfinfra and got the link from bdemers: [1]. He says it will > > change to [2] whenever Nexus is upgraded. > > Thanks! > > Just to clarify: is it just the link that will change, or will the API > change as well? > > > Matt > > [1] > > > https://repository.apache.org/nexus-core-documentation-plugin/core/docs/index.html > > [2] > > > https://repository.apache.org/nexus-restlet1x-plugin/default/docs/index.html > > > > > > > > On Tue, Oct 15, 2013 at 12:23 PM, sebb wrote: > >> > >> On 15 October 2013 17:54, Matt Benson wrote: > >> > We should probably investigate whether Nexus's REST APIs would be of > any > >> > use here; seemingly they would make it much more difficult to > >> > inadvertently > >> > delete the wrong file(s). > >> > >> I did try to find out about them. > >> Unfortunately they are not documented anywhere public that I could > >> find (and it appears they may not be stable). > >> I did make some progress by recording the GUI, but that is obviously not > >> ideal. > >> > >> > Matt > >> > > >> > > >> > On Tue, Oct 15, 2013 at 11:33 AM, sebb wrote: > >> > > >> >> On 14 October 2013 02:21, Ralph Goers > >> >> wrote: > >> >> > > >> >> > On Oct 13, 2013, at 4:31 PM, sebb wrote: > >> >> > > >> >> >> Recently, I found that the Maven project RMs don't bother removing > >> >> these. > >> >> >> So the files are released to Maven Central with the rest. > >> >> >> I assume that the Maven Central administrators don't care about > the > >> >> >> extra space needed. > >> >> >> > >> >> >> Now ASF source releases must be provided via the ASF mirror > system. > >> >> >> There does not seem to be any ruling on whether having additional > >> >> >> copies of the source release elsehere is allowed or not. > >> >> >> > >> >> >> I tried asking on Infra whether source releases should only be > >> >> >> published to the ASF mirror system, but got no answer. > >> >> >> Perhaps someone else would like to try? > >> >> >> > >> >> >> It would obviously be a lot easier if the Nexus directory did not > >> >> >> have > >> >> >> to be purged of these files, as this has to be carefully > >> >> >> co-ordinated > >> >> >> with copying the files for the ASF mirror SVN repo. > >> >> > > >> >> > Whether they have to be removed or not as a user I find them being > >> >> published to Maven central to be annoying since they are pretty much > >> >> useless as Maven artifacts. > >> >> > >> >> Indeed. > >> >> > >> >> The issue here is that deleting files from a closed staging area is > >> >> prone to errors as the Nexus GUI is quite fiddly (and the > confirmation > >> >> pop-up does not show the name of the file being deleted). > >> >> > >> >> > > >> >> >> > >> >> >>> I gave up trying to remove the absurd .asc.sha1 and > >> >> >>> .asc.md5 files for JCI, there was too many of them (12 files per > >> >> >>> artifact, 6 artifacts). > >> >> >> > >> >> >> That could be automated (I started working on a tool to do this, > but > >> >> >> other things intervened). > >> >> >> It's a long-standing Maven bug. The files can be left, but it > makes > >> >> >> checking the directory tedious. > >> >> > > >> >> > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c. > I'm > >> >> not sure why rm *.asc.md5 is a problem. Even if they are in separate > >> >> directories the find command works pretty well. > >> >> > >> >> Find and rm do not work on Nexus, which is one place where the > >> >> spurious files are annoying. > >> >> Also it's easy to delete the wrong file in Nexus (so this should be > >> >> done before closing the staging area - if it is done at all) > >> >> > >> >> > Ralph > >> >> > > >> >> > >> >> - > >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >> For additional commands, e-mail: dev-h...@commons.apache.org > >> >> > >> >> > > > > >
Re: [DISCUSS] Creating Project for Release Process Testing...
On 15 October 2013 19:33, Matt Benson wrote: > Asked on #asfinfra and got the link from bdemers: [1]. He says it will > change to [2] whenever Nexus is upgraded. Thanks! Just to clarify: is it just the link that will change, or will the API change as well? > Matt > [1] > https://repository.apache.org/nexus-core-documentation-plugin/core/docs/index.html > [2] > https://repository.apache.org/nexus-restlet1x-plugin/default/docs/index.html > > > > On Tue, Oct 15, 2013 at 12:23 PM, sebb wrote: >> >> On 15 October 2013 17:54, Matt Benson wrote: >> > We should probably investigate whether Nexus's REST APIs would be of any >> > use here; seemingly they would make it much more difficult to >> > inadvertently >> > delete the wrong file(s). >> >> I did try to find out about them. >> Unfortunately they are not documented anywhere public that I could >> find (and it appears they may not be stable). >> I did make some progress by recording the GUI, but that is obviously not >> ideal. >> >> > Matt >> > >> > >> > On Tue, Oct 15, 2013 at 11:33 AM, sebb wrote: >> > >> >> On 14 October 2013 02:21, Ralph Goers >> >> wrote: >> >> > >> >> > On Oct 13, 2013, at 4:31 PM, sebb wrote: >> >> > >> >> >> Recently, I found that the Maven project RMs don't bother removing >> >> these. >> >> >> So the files are released to Maven Central with the rest. >> >> >> I assume that the Maven Central administrators don't care about the >> >> >> extra space needed. >> >> >> >> >> >> Now ASF source releases must be provided via the ASF mirror system. >> >> >> There does not seem to be any ruling on whether having additional >> >> >> copies of the source release elsehere is allowed or not. >> >> >> >> >> >> I tried asking on Infra whether source releases should only be >> >> >> published to the ASF mirror system, but got no answer. >> >> >> Perhaps someone else would like to try? >> >> >> >> >> >> It would obviously be a lot easier if the Nexus directory did not >> >> >> have >> >> >> to be purged of these files, as this has to be carefully >> >> >> co-ordinated >> >> >> with copying the files for the ASF mirror SVN repo. >> >> > >> >> > Whether they have to be removed or not as a user I find them being >> >> published to Maven central to be annoying since they are pretty much >> >> useless as Maven artifacts. >> >> >> >> Indeed. >> >> >> >> The issue here is that deleting files from a closed staging area is >> >> prone to errors as the Nexus GUI is quite fiddly (and the confirmation >> >> pop-up does not show the name of the file being deleted). >> >> >> >> > >> >> >> >> >> >>> I gave up trying to remove the absurd .asc.sha1 and >> >> >>> .asc.md5 files for JCI, there was too many of them (12 files per >> >> >>> artifact, 6 artifacts). >> >> >> >> >> >> That could be automated (I started working on a tool to do this, but >> >> >> other things intervened). >> >> >> It's a long-standing Maven bug. The files can be left, but it makes >> >> >> checking the directory tedious. >> >> > >> >> > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c. I'm >> >> not sure why rm *.asc.md5 is a problem. Even if they are in separate >> >> directories the find command works pretty well. >> >> >> >> Find and rm do not work on Nexus, which is one place where the >> >> spurious files are annoying. >> >> Also it's easy to delete the wrong file in Nexus (so this should be >> >> done before closing the staging area - if it is done at all) >> >> >> >> > Ralph >> >> > >> >> >> >> - >> >> 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
Re: [DISCUSS] Creating Project for Release Process Testing...
Asked on #asfinfra and got the link from bdemers: [1]. He says it will change to [2] whenever Nexus is upgraded. Matt [1] https://repository.apache.org/nexus-core-documentation-plugin/core/docs/index.html [2] https://repository.apache.org/nexus-restlet1x-plugin/default/docs/index.html On Tue, Oct 15, 2013 at 12:23 PM, sebb wrote: > On 15 October 2013 17:54, Matt Benson wrote: > > We should probably investigate whether Nexus's REST APIs would be of any > > use here; seemingly they would make it much more difficult to > inadvertently > > delete the wrong file(s). > > I did try to find out about them. > Unfortunately they are not documented anywhere public that I could > find (and it appears they may not be stable). > I did make some progress by recording the GUI, but that is obviously not > ideal. > > > Matt > > > > > > On Tue, Oct 15, 2013 at 11:33 AM, sebb wrote: > > > >> On 14 October 2013 02:21, Ralph Goers > wrote: > >> > > >> > On Oct 13, 2013, at 4:31 PM, sebb wrote: > >> > > >> >> Recently, I found that the Maven project RMs don't bother removing > >> these. > >> >> So the files are released to Maven Central with the rest. > >> >> I assume that the Maven Central administrators don't care about the > >> >> extra space needed. > >> >> > >> >> Now ASF source releases must be provided via the ASF mirror system. > >> >> There does not seem to be any ruling on whether having additional > >> >> copies of the source release elsehere is allowed or not. > >> >> > >> >> I tried asking on Infra whether source releases should only be > >> >> published to the ASF mirror system, but got no answer. > >> >> Perhaps someone else would like to try? > >> >> > >> >> It would obviously be a lot easier if the Nexus directory did not > have > >> >> to be purged of these files, as this has to be carefully co-ordinated > >> >> with copying the files for the ASF mirror SVN repo. > >> > > >> > Whether they have to be removed or not as a user I find them being > >> published to Maven central to be annoying since they are pretty much > >> useless as Maven artifacts. > >> > >> Indeed. > >> > >> The issue here is that deleting files from a closed staging area is > >> prone to errors as the Nexus GUI is quite fiddly (and the confirmation > >> pop-up does not show the name of the file being deleted). > >> > >> > > >> >> > >> >>> I gave up trying to remove the absurd .asc.sha1 and > >> >>> .asc.md5 files for JCI, there was too many of them (12 files per > >> >>> artifact, 6 artifacts). > >> >> > >> >> That could be automated (I started working on a tool to do this, but > >> >> other things intervened). > >> >> It's a long-standing Maven bug. The files can be left, but it makes > >> >> checking the directory tedious. > >> > > >> > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c. I'm > >> not sure why rm *.asc.md5 is a problem. Even if they are in separate > >> directories the find command works pretty well. > >> > >> Find and rm do not work on Nexus, which is one place where the > >> spurious files are annoying. > >> Also it's easy to delete the wrong file in Nexus (so this should be > >> done before closing the staging area - if it is done at all) > >> > >> > Ralph > >> > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> >
Re: [DISCUSS] Creating Project for Release Process Testing...
On 15 October 2013 17:54, Matt Benson wrote: > We should probably investigate whether Nexus's REST APIs would be of any > use here; seemingly they would make it much more difficult to inadvertently > delete the wrong file(s). I did try to find out about them. Unfortunately they are not documented anywhere public that I could find (and it appears they may not be stable). I did make some progress by recording the GUI, but that is obviously not ideal. > Matt > > > On Tue, Oct 15, 2013 at 11:33 AM, sebb wrote: > >> On 14 October 2013 02:21, Ralph Goers wrote: >> > >> > On Oct 13, 2013, at 4:31 PM, sebb wrote: >> > >> >> Recently, I found that the Maven project RMs don't bother removing >> these. >> >> So the files are released to Maven Central with the rest. >> >> I assume that the Maven Central administrators don't care about the >> >> extra space needed. >> >> >> >> Now ASF source releases must be provided via the ASF mirror system. >> >> There does not seem to be any ruling on whether having additional >> >> copies of the source release elsehere is allowed or not. >> >> >> >> I tried asking on Infra whether source releases should only be >> >> published to the ASF mirror system, but got no answer. >> >> Perhaps someone else would like to try? >> >> >> >> It would obviously be a lot easier if the Nexus directory did not have >> >> to be purged of these files, as this has to be carefully co-ordinated >> >> with copying the files for the ASF mirror SVN repo. >> > >> > Whether they have to be removed or not as a user I find them being >> published to Maven central to be annoying since they are pretty much >> useless as Maven artifacts. >> >> Indeed. >> >> The issue here is that deleting files from a closed staging area is >> prone to errors as the Nexus GUI is quite fiddly (and the confirmation >> pop-up does not show the name of the file being deleted). >> >> > >> >> >> >>> I gave up trying to remove the absurd .asc.sha1 and >> >>> .asc.md5 files for JCI, there was too many of them (12 files per >> >>> artifact, 6 artifacts). >> >> >> >> That could be automated (I started working on a tool to do this, but >> >> other things intervened). >> >> It's a long-standing Maven bug. The files can be left, but it makes >> >> checking the directory tedious. >> > >> > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c. I'm >> not sure why rm *.asc.md5 is a problem. Even if they are in separate >> directories the find command works pretty well. >> >> Find and rm do not work on Nexus, which is one place where the >> spurious files are annoying. >> Also it's easy to delete the wrong file in Nexus (so this should be >> done before closing the staging area - if it is done at all) >> >> > Ralph >> > >> >> - >> 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
Re: [DISCUSS] Creating Project for Release Process Testing...
We should probably investigate whether Nexus's REST APIs would be of any use here; seemingly they would make it much more difficult to inadvertently delete the wrong file(s). Matt On Tue, Oct 15, 2013 at 11:33 AM, sebb wrote: > On 14 October 2013 02:21, Ralph Goers wrote: > > > > On Oct 13, 2013, at 4:31 PM, sebb wrote: > > > >> Recently, I found that the Maven project RMs don't bother removing > these. > >> So the files are released to Maven Central with the rest. > >> I assume that the Maven Central administrators don't care about the > >> extra space needed. > >> > >> Now ASF source releases must be provided via the ASF mirror system. > >> There does not seem to be any ruling on whether having additional > >> copies of the source release elsehere is allowed or not. > >> > >> I tried asking on Infra whether source releases should only be > >> published to the ASF mirror system, but got no answer. > >> Perhaps someone else would like to try? > >> > >> It would obviously be a lot easier if the Nexus directory did not have > >> to be purged of these files, as this has to be carefully co-ordinated > >> with copying the files for the ASF mirror SVN repo. > > > > Whether they have to be removed or not as a user I find them being > published to Maven central to be annoying since they are pretty much > useless as Maven artifacts. > > Indeed. > > The issue here is that deleting files from a closed staging area is > prone to errors as the Nexus GUI is quite fiddly (and the confirmation > pop-up does not show the name of the file being deleted). > > > > >> > >>> I gave up trying to remove the absurd .asc.sha1 and > >>> .asc.md5 files for JCI, there was too many of them (12 files per > >>> artifact, 6 artifacts). > >> > >> That could be automated (I started working on a tool to do this, but > >> other things intervened). > >> It's a long-standing Maven bug. The files can be left, but it makes > >> checking the directory tedious. > > > > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c. I'm > not sure why rm *.asc.md5 is a problem. Even if they are in separate > directories the find command works pretty well. > > Find and rm do not work on Nexus, which is one place where the > spurious files are annoying. > Also it's easy to delete the wrong file in Nexus (so this should be > done before closing the staging area - if it is done at all) > > > Ralph > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [DISCUSS] Creating Project for Release Process Testing...
On 14 October 2013 02:21, Ralph Goers wrote: > > On Oct 13, 2013, at 4:31 PM, sebb wrote: > >> Recently, I found that the Maven project RMs don't bother removing these. >> So the files are released to Maven Central with the rest. >> I assume that the Maven Central administrators don't care about the >> extra space needed. >> >> Now ASF source releases must be provided via the ASF mirror system. >> There does not seem to be any ruling on whether having additional >> copies of the source release elsehere is allowed or not. >> >> I tried asking on Infra whether source releases should only be >> published to the ASF mirror system, but got no answer. >> Perhaps someone else would like to try? >> >> It would obviously be a lot easier if the Nexus directory did not have >> to be purged of these files, as this has to be carefully co-ordinated >> with copying the files for the ASF mirror SVN repo. > > Whether they have to be removed or not as a user I find them being published > to Maven central to be annoying since they are pretty much useless as Maven > artifacts. Indeed. The issue here is that deleting files from a closed staging area is prone to errors as the Nexus GUI is quite fiddly (and the confirmation pop-up does not show the name of the file being deleted). > >> >>> I gave up trying to remove the absurd .asc.sha1 and >>> .asc.md5 files for JCI, there was too many of them (12 files per >>> artifact, 6 artifacts). >> >> That could be automated (I started working on a tool to do this, but >> other things intervened). >> It's a long-standing Maven bug. The files can be left, but it makes >> checking the directory tedious. > > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c. I'm not sure > why rm *.asc.md5 is a problem. Even if they are in separate directories the > find command works pretty well. Find and rm do not work on Nexus, which is one place where the spurious files are annoying. Also it's easy to delete the wrong file in Nexus (so this should be done before closing the staging area - if it is done at all) > Ralph > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Creating Project for Release Process Testing...
On Oct 13, 2013, at 4:31 PM, sebb wrote: > Recently, I found that the Maven project RMs don't bother removing these. > So the files are released to Maven Central with the rest. > I assume that the Maven Central administrators don't care about the > extra space needed. > > Now ASF source releases must be provided via the ASF mirror system. > There does not seem to be any ruling on whether having additional > copies of the source release elsehere is allowed or not. > > I tried asking on Infra whether source releases should only be > published to the ASF mirror system, but got no answer. > Perhaps someone else would like to try? > > It would obviously be a lot easier if the Nexus directory did not have > to be purged of these files, as this has to be carefully co-ordinated > with copying the files for the ASF mirror SVN repo. Whether they have to be removed or not as a user I find them being published to Maven central to be annoying since they are pretty much useless as Maven artifacts. > >> I gave up trying to remove the absurd .asc.sha1 and >> .asc.md5 files for JCI, there was too many of them (12 files per >> artifact, 6 artifacts). > > That could be automated (I started working on a tool to do this, but > other things intervened). > It's a long-standing Maven bug. The files can be left, but it makes > checking the directory tedious. See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c. I'm not sure why rm *.asc.md5 is a problem. Even if they are in separate directories the find command works pretty well. Ralph
Re: [DISCUSS] Creating Project for Release Process Testing...
On 11 October 2013 10:23, Emmanuel Bourg wrote: > Le 11/10/2013 01:35, Matt Benson a écrit : >> We're all still talking about the release process, but in all honesty I've >> not done it for several years at Commons. I think it would be immensely >> helpful for those of us who have been at least part way through the process >> fairly recently (Emmanuel, Gary, others?) to present your recollections of >> what was difficult, so that we can have a real list of things to try and >> address. > > Here is my quick feed back on the release process. For the record I > prepared the release on Windows by following the 'Using Nexus for > Commons Maven releases' guide [1]. I also took some bits from the > 'Releasing Components' guide [2] (unifying these documents would be a > good start). > > 1. The initial setup is a bit tedious. Generating the GPG key, uploading > it, configuring the agent, adding the Maven settings. This is not fun > and sometimes frustrating (I didn't set my ASF password properly in the > Maven settings and I had to reset it twice. Nexus rejected my uploads > with a 401 error but I didn't figure my account was locked until I found > myself unable to commit a change in SVN). Hopefully all of this is > performed only once. > > 2. The Nexus UI is a bit confusing when you are not used to it. Between > User Managed Repositories, Nexus Managed Repositories and Staging > Repositories it wasn't obvious at the first glance to see where the > action was supposed to take place. A mini howto with annotated > screenshots would help. > > 3. Having to drop manually the -src and -bin artifacts uploaded to Nexus > is annoying. Recently, I found that the Maven project RMs don't bother removing these. So the files are released to Maven Central with the rest. I assume that the Maven Central administrators don't care about the extra space needed. Now ASF source releases must be provided via the ASF mirror system. There does not seem to be any ruling on whether having additional copies of the source release elsehere is allowed or not. I tried asking on Infra whether source releases should only be published to the ASF mirror system, but got no answer. Perhaps someone else would like to try? It would obviously be a lot easier if the Nexus directory did not have to be purged of these files, as this has to be carefully co-ordinated with copying the files for the ASF mirror SVN repo. > I gave up trying to remove the absurd .asc.sha1 and > .asc.md5 files for JCI, there was too many of them (12 files per > artifact, 6 artifacts). That could be automated (I started working on a tool to do this, but other things intervened). It's a long-standing Maven bug. The files can be left, but it makes checking the directory tedious. > 4. Preparing the release notes is time consuming. I know it can be > generated from JIRA but I don't find that descriptive enough. Using the > Maven changes.xml is the best solution, but it has to be maintained > properly during the development (it wasn't for JCI). With NET I went through JIRA looking at the "Fix" version to check that all the issues were in changes.xml. > 5. I created the tag manually, that was simple enough. I don't trust the > release plugin. I guess I need some training on a dummy project. Due to > minor errors spotted afterward I had to recreate the tag twice. So I > suggest creating the tag only when you have reviewed everything and > about to send the vote mail. The release plugin works best if the release vote succeeds; it's messy if a respin is needed. There will be SNAPSHOT releases (generated by CI) with the next version in them. If the release vote fails, these can hang around for a while, causing possible confusion once trunk moves on as they will become stale. > 6. 'mvn site:stage-deploy' doesn't work. I got the message > "maven.site.deploy.skip = true: Skipping site deployment". This property > is set in the parent pom! I had to tar the site, upload and install it > manually on people.apache.org. > > 7. I would like a [VOTE] mail generator :) > > 8. Uploading the source and the binary archives on people.apache.org > implies too many manual steps. This has to be automated (with a Maven > plugin attached to the deploy phase?). Automating that was one of the plugins I started working on. However, it must be done after the vote has succeeded, unless the files are copied to the dev (staging) repo. In which case there are then two staging areas to consider for the vote. It's easier to use Nexus for both. None of these problems are due to using SVN; most (all?) of these problems are due to using Maven. > > Emmanuel Bourg > > [1] http://wiki.apache.org/commons/UsingNexus > [2] http://commons.apache.org/releases/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > ---
Re: [DISCUSS] Creating Project for Release Process Testing...
On 11 October 2013 05:16, Stefan Bodewig wrote: > On 2013-10-11, Matt Benson wrote: > >> We're all still talking about the release process, but in all honesty I've >> not done it for several years at Commons. I think it would be immensely >> helpful for those of us who have been at least part way through the process >> fairly recently (Emmanuel, Gary, others?) to present your recollections of >> what was difficult, so that we can have a real list of things to try and >> address. > > Not sure whether May is recent enough :-) > > AFAIR there isn't anything difficult. The major pain point for me is > the sheer number of manual steps - with it comes a big number of > opportunities to make mistakes - and the time it takes. > > One detail I just figured out after my third release was that I can > start the gpg-agent before running "mvn deploy" - and I think I've > documented that. Without that I had to type in my passphrase for every > single artifact. With my setup, the gpg-agent is started automatically. I use Window; maybe gpg works differently on Unix. > I prefer the "create the tag manually and avoid the release plugin" Ditto. > approach but don't think there is a big difference here. > Stefan > > - > 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
Re: [DISCUSS] Creating Project for Release Process Testing...
Le 12/10/2013 10:07, Olivier Lamy a écrit : > Why removing those files? It's is strictly forbidden by any Apache > rules to have those? No, but it just clutters Maven Central. The .asc file contains a signed hash of the file, there is no need to have two additional hashes of a hash. > why creating tag manually? I believe release plugin does it. I'm just not used to it, so I picked the safest solution for me. This is where the test component will be useful, it will allow new release managers to experiment with the tools involved. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Creating Project for Release Process Testing...
Phil, I'm for whatever makes it easier. In the new release test project, let's start "green field" and see what we come up with. If we see enough boilerplate to merit a parent, then we will extract those bits and make one. If not, then it's every component for themselves. On Sunday, October 13, 2013, Phil Steitz wrote: > On 10/11/13 3:53 AM, Gilles wrote: > > On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote: > >> We're all still talking about the release process, but in all > >> honesty I've > >> not done it for several years at Commons. I think it would be > >> immensely > >> helpful for those of us who have been at least part way through > >> the process > >> fairly recently (Emmanuel, Gary, others?) to present your > >> recollections of > >> what was difficult, so that we can have a real list of things to > >> try and > >> address. > >> > > > > There is a mini-howto for Commons Math here: > > > > > https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt > > > > The aim was to provide a fool-proof, step-by-step recipe, which > > the "official" > > Wiki documents were _not_: The missing bits were filled as a > > summary of my > > interaction with the ML (cf. archive). > > [Luc upgraded the document after the CMS change.] > > > > Nothing is "complicated"; following the recipe should allow anyone > > to make a > > release. > > As was noted in another post: > > * several steps could be made faster with scripting > > +1 and once again THANKs for documenting this stuff for [math], > Gilles. I have not cut a release since the forced Nexus days, but > before then, I always used shell scripts that I eventually committed > to svn to make it "just push the button" the next time I did it. An > example is [1], which no longer works due to changes in commons > parent, maven plugins and the Nexus requirement; but if and when I > cut another release there or on anything else, I will likely just > update it so .(n+k) are easy. After doing the work to create [1] > for [pool] 1.5, 1.5.1-1.5.7 were trivial for me. The problem with > this approach is that it requires a unix shell and it also punts the > "let maven automagially do everything" desire. Personally, I much > prefer the srcipt approach as I know exactly what is happening. > > This brings up another point that has been sort of in the background > here. I don't think it is a defeat to have individual components > have their own RM READMEs. Trying to solve the problem generically > for all components increases the degree of difficulty and the > probability that people will run into little problems. I have felt > this way for a long time regarding the commons parent pom as well. > It might be better to destandardize a little, slim down the parent > (or dump it altogether) and allow component RMs to develop things > like [1] and Gilles' instructions above, without aiming to solve the > problem generically for all components. When you think about it, > what we have have been struggling with here is generic release > tooling for java components @apache, which is in theory possible, > but with sometimes flaky and changing underlying tools (maven > plugins, nexus) and little edge cases to consider at the component > level, we end up burning ridiculously more energy and having to > fiddle more often than if we just maintained little scripts/READMEs > at the component level. We could maintain general instructions > explaining what is *required* and just use the time honored Commons > tradition of imitating other components to get and keep the > individual RC scripts working. As a concrete example, I would like > to see us experiment with the tomcat approach to deployment [2] for > pool2 and dbcp2, but I don't want to force everyone down this path > or get everyone to agree to it. > > Phil > > [1] > https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pool-RC.sh > [2] http://markmail.org/message/kkualb7xse2mcwkd > > > * removing spurious files from Nexus is a pain after a few RCs > > > > > > Regards, > > Gilles > > > > > > - > > 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 > >
Re: [DISCUSS] Creating Project for Release Process Testing...
I understand your frustration, Phil, particularly if you're the type who has never liked the flavor of the Maven kool-aid... I know I struggled fruitlessly for years against Maven! However, the biggest benefit I see to the parent pom is the site management. I can't justify us propping up some custom site management solution, personally. I suppose that if we can get the Maven fluido skin working and agree on a bootstrap style, it could become an option for a given component to use the straight CMS with that style and bypass the Maven site. But I do think some measure of cosmetic unity among the component sites should be maintained. Matt On Oct 13, 2013 12:20 PM, "Phil Steitz" wrote: > On 10/11/13 3:53 AM, Gilles wrote: > > On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote: > >> We're all still talking about the release process, but in all > >> honesty I've > >> not done it for several years at Commons. I think it would be > >> immensely > >> helpful for those of us who have been at least part way through > >> the process > >> fairly recently (Emmanuel, Gary, others?) to present your > >> recollections of > >> what was difficult, so that we can have a real list of things to > >> try and > >> address. > >> > > > > There is a mini-howto for Commons Math here: > > > > > https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt > > > > The aim was to provide a fool-proof, step-by-step recipe, which > > the "official" > > Wiki documents were _not_: The missing bits were filled as a > > summary of my > > interaction with the ML (cf. archive). > > [Luc upgraded the document after the CMS change.] > > > > Nothing is "complicated"; following the recipe should allow anyone > > to make a > > release. > > As was noted in another post: > > * several steps could be made faster with scripting > > +1 and once again THANKs for documenting this stuff for [math], > Gilles. I have not cut a release since the forced Nexus days, but > before then, I always used shell scripts that I eventually committed > to svn to make it "just push the button" the next time I did it. An > example is [1], which no longer works due to changes in commons > parent, maven plugins and the Nexus requirement; but if and when I > cut another release there or on anything else, I will likely just > update it so .(n+k) are easy. After doing the work to create [1] > for [pool] 1.5, 1.5.1-1.5.7 were trivial for me. The problem with > this approach is that it requires a unix shell and it also punts the > "let maven automagially do everything" desire. Personally, I much > prefer the srcipt approach as I know exactly what is happening. > > This brings up another point that has been sort of in the background > here. I don't think it is a defeat to have individual components > have their own RM READMEs. Trying to solve the problem generically > for all components increases the degree of difficulty and the > probability that people will run into little problems. I have felt > this way for a long time regarding the commons parent pom as well. > It might be better to destandardize a little, slim down the parent > (or dump it altogether) and allow component RMs to develop things > like [1] and Gilles' instructions above, without aiming to solve the > problem generically for all components. When you think about it, > what we have have been struggling with here is generic release > tooling for java components @apache, which is in theory possible, > but with sometimes flaky and changing underlying tools (maven > plugins, nexus) and little edge cases to consider at the component > level, we end up burning ridiculously more energy and having to > fiddle more often than if we just maintained little scripts/READMEs > at the component level. We could maintain general instructions > explaining what is *required* and just use the time honored Commons > tradition of imitating other components to get and keep the > individual RC scripts working. As a concrete example, I would like > to see us experiment with the tomcat approach to deployment [2] for > pool2 and dbcp2, but I don't want to force everyone down this path > or get everyone to agree to it. > > Phil > > [1] > https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pool-RC.sh > [2] http://markmail.org/message/kkualb7xse2mcwkd > > > * removing spurious files from Nexus is a pain after a few RCs > > > > > > Regards, > > Gilles > > > > > > - > > 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 > >
Re: [DISCUSS] Creating Project for Release Process Testing...
On 10/11/13 3:53 AM, Gilles wrote: > On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote: >> We're all still talking about the release process, but in all >> honesty I've >> not done it for several years at Commons. I think it would be >> immensely >> helpful for those of us who have been at least part way through >> the process >> fairly recently (Emmanuel, Gary, others?) to present your >> recollections of >> what was difficult, so that we can have a real list of things to >> try and >> address. >> > > There is a mini-howto for Commons Math here: > > https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt > > The aim was to provide a fool-proof, step-by-step recipe, which > the "official" > Wiki documents were _not_: The missing bits were filled as a > summary of my > interaction with the ML (cf. archive). > [Luc upgraded the document after the CMS change.] > > Nothing is "complicated"; following the recipe should allow anyone > to make a > release. > As was noted in another post: > * several steps could be made faster with scripting +1 and once again THANKs for documenting this stuff for [math], Gilles. I have not cut a release since the forced Nexus days, but before then, I always used shell scripts that I eventually committed to svn to make it "just push the button" the next time I did it. An example is [1], which no longer works due to changes in commons parent, maven plugins and the Nexus requirement; but if and when I cut another release there or on anything else, I will likely just update it so .(n+k) are easy. After doing the work to create [1] for [pool] 1.5, 1.5.1-1.5.7 were trivial for me. The problem with this approach is that it requires a unix shell and it also punts the "let maven automagially do everything" desire. Personally, I much prefer the srcipt approach as I know exactly what is happening. This brings up another point that has been sort of in the background here. I don't think it is a defeat to have individual components have their own RM READMEs. Trying to solve the problem generically for all components increases the degree of difficulty and the probability that people will run into little problems. I have felt this way for a long time regarding the commons parent pom as well. It might be better to destandardize a little, slim down the parent (or dump it altogether) and allow component RMs to develop things like [1] and Gilles' instructions above, without aiming to solve the problem generically for all components. When you think about it, what we have have been struggling with here is generic release tooling for java components @apache, which is in theory possible, but with sometimes flaky and changing underlying tools (maven plugins, nexus) and little edge cases to consider at the component level, we end up burning ridiculously more energy and having to fiddle more often than if we just maintained little scripts/READMEs at the component level. We could maintain general instructions explaining what is *required* and just use the time honored Commons tradition of imitating other components to get and keep the individual RC scripts working. As a concrete example, I would like to see us experiment with the tomcat approach to deployment [2] for pool2 and dbcp2, but I don't want to force everyone down this path or get everyone to agree to it. Phil [1] https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pool-RC.sh [2] http://markmail.org/message/kkualb7xse2mcwkd > * removing spurious files from Nexus is a pain after a few RCs > > > Regards, > Gilles > > > - > 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
Re: [DISCUSS] Creating Project for Release Process Testing...
JIRA created: https://issues.apache.org/jira/browse/INFRA-6859 On Sun, Oct 13, 2013 at 4:17 AM, Siegfried Goeschl wrote: > +1 on that > > I did a few releases over the year and had ALWAYS issues - for me the > biggest obstacles are > > * getting a positive vote on a RC (that's a different story) > * getting the release out of the door - a test project would help immensely > since I can blow it up without any consequences > > Cheers, > > Siegfried Goeschl > > > On 10.10.13 17:29, Gary Gregory wrote: >> >> Nice idea, but push it to central to test the whole chain. >> >> G >> >> On Thu, Oct 10, 2013 at 11:24 AM, James Carman >> wrote: >>> >>> Why don't we create a real project that we can cut real releases on to >>> test our release procedures? Perhaps we can set it up so that it >>> doesn't sync with central and just gets staged locally. This way, we >>> can test out changes to the release process and see how they work. >>> Also, a new release manager can play around with that project and get >>> it right before diving into the real work. >>> >>> - >>> 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
Re: [DISCUSS] Creating Project for Release Process Testing...
+1 on that I did a few releases over the year and had ALWAYS issues - for me the biggest obstacles are * getting a positive vote on a RC (that's a different story) * getting the release out of the door - a test project would help immensely since I can blow it up without any consequences Cheers, Siegfried Goeschl On 10.10.13 17:29, Gary Gregory wrote: Nice idea, but push it to central to test the whole chain. G On Thu, Oct 10, 2013 at 11:24 AM, James Carman wrote: Why don't we create a real project that we can cut real releases on to test our release procedures? Perhaps we can set it up so that it doesn't sync with central and just gets staged locally. This way, we can test out changes to the release process and see how they work. Also, a new release manager can play around with that project and get it right before diving into the real work. - 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
Re: [DISCUSS] Creating Project for Release Process Testing...
On 11 October 2013 20:23, Emmanuel Bourg wrote: > Le 11/10/2013 01:35, Matt Benson a écrit : >> We're all still talking about the release process, but in all honesty I've >> not done it for several years at Commons. I think it would be immensely >> helpful for those of us who have been at least part way through the process >> fairly recently (Emmanuel, Gary, others?) to present your recollections of >> what was difficult, so that we can have a real list of things to try and >> address. > > Here is my quick feed back on the release process. For the record I > prepared the release on Windows by following the 'Using Nexus for > Commons Maven releases' guide [1]. I also took some bits from the > 'Releasing Components' guide [2] (unifying these documents would be a > good start). > > 1. The initial setup is a bit tedious. Generating the GPG key, uploading > it, configuring the agent, adding the Maven settings. This is not fun > and sometimes frustrating (I didn't set my ASF password properly in the > Maven settings and I had to reset it twice. Nexus rejected my uploads > with a 401 error but I didn't figure my account was locked until I found > myself unable to commit a change in SVN). Hopefully all of this is > performed only once. > > 2. The Nexus UI is a bit confusing when you are not used to it. Between > User Managed Repositories, Nexus Managed Repositories and Staging > Repositories it wasn't obvious at the first glance to see where the > action was supposed to take place. A mini howto with annotated > screenshots would help. > > 3. Having to drop manually the -src and -bin artifacts uploaded to Nexus > is annoying. I gave up trying to remove the absurd .asc.sha1 and > .asc.md5 files for JCI, there was too many of them (12 files per > artifact, 6 artifacts). Why removing those files? It's is strictly forbidden by any Apache rules to have those? > > 4. Preparing the release notes is time consuming. I know it can be > generated from JIRA but I don't find that descriptive enough. Using the > Maven changes.xml is the best solution, but it has to be maintained > properly during the development (it wasn't for JCI). > > 5. I created the tag manually, that was simple enough. I don't trust the > release plugin. I guess I need some training on a dummy project. Due to > minor errors spotted afterward I had to recreate the tag twice. So I > suggest creating the tag only when you have reviewed everything and > about to send the vote mail. why creating tag manually? I believe release plugin does it. > > 6. 'mvn site:stage-deploy' doesn't work. I got the message > "maven.site.deploy.skip = true: Skipping site deployment". This property > is set in the parent pom! I had to tar the site, upload and install it > manually on people.apache.org. probably something not complicated to fix. > > 7. I would like a [VOTE] mail generator :) Agree too. > > 8. Uploading the source and the binary archives on people.apache.org > implies too many manual steps. This has to be automated (with a Maven > plugin attached to the deploy phase?). > Agree too (something I wanted to do but not having time to work on it). I don't understand why you guys are adding manual steps (whereas tools exists). > > Emmanuel Bourg > > [1] http://wiki.apache.org/commons/UsingNexus > [2] http://commons.apache.org/releases/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Creating Project for Release Process Testing...
On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote: We're all still talking about the release process, but in all honesty I've not done it for several years at Commons. I think it would be immensely helpful for those of us who have been at least part way through the process fairly recently (Emmanuel, Gary, others?) to present your recollections of what was difficult, so that we can have a real list of things to try and address. There is a mini-howto for Commons Math here: https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt The aim was to provide a fool-proof, step-by-step recipe, which the "official" Wiki documents were _not_: The missing bits were filled as a summary of my interaction with the ML (cf. archive). [Luc upgraded the document after the CMS change.] Nothing is "complicated"; following the recipe should allow anyone to make a release. As was noted in another post: * several steps could be made faster with scripting * removing spurious files from Nexus is a pain after a few RCs Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Creating Project for Release Process Testing...
Le 11/10/2013 01:35, Matt Benson a écrit : > We're all still talking about the release process, but in all honesty I've > not done it for several years at Commons. I think it would be immensely > helpful for those of us who have been at least part way through the process > fairly recently (Emmanuel, Gary, others?) to present your recollections of > what was difficult, so that we can have a real list of things to try and > address. Here is my quick feed back on the release process. For the record I prepared the release on Windows by following the 'Using Nexus for Commons Maven releases' guide [1]. I also took some bits from the 'Releasing Components' guide [2] (unifying these documents would be a good start). 1. The initial setup is a bit tedious. Generating the GPG key, uploading it, configuring the agent, adding the Maven settings. This is not fun and sometimes frustrating (I didn't set my ASF password properly in the Maven settings and I had to reset it twice. Nexus rejected my uploads with a 401 error but I didn't figure my account was locked until I found myself unable to commit a change in SVN). Hopefully all of this is performed only once. 2. The Nexus UI is a bit confusing when you are not used to it. Between User Managed Repositories, Nexus Managed Repositories and Staging Repositories it wasn't obvious at the first glance to see where the action was supposed to take place. A mini howto with annotated screenshots would help. 3. Having to drop manually the -src and -bin artifacts uploaded to Nexus is annoying. I gave up trying to remove the absurd .asc.sha1 and .asc.md5 files for JCI, there was too many of them (12 files per artifact, 6 artifacts). 4. Preparing the release notes is time consuming. I know it can be generated from JIRA but I don't find that descriptive enough. Using the Maven changes.xml is the best solution, but it has to be maintained properly during the development (it wasn't for JCI). 5. I created the tag manually, that was simple enough. I don't trust the release plugin. I guess I need some training on a dummy project. Due to minor errors spotted afterward I had to recreate the tag twice. So I suggest creating the tag only when you have reviewed everything and about to send the vote mail. 6. 'mvn site:stage-deploy' doesn't work. I got the message "maven.site.deploy.skip = true: Skipping site deployment". This property is set in the parent pom! I had to tar the site, upload and install it manually on people.apache.org. 7. I would like a [VOTE] mail generator :) 8. Uploading the source and the binary archives on people.apache.org implies too many manual steps. This has to be automated (with a Maven plugin attached to the deploy phase?). Emmanuel Bourg [1] http://wiki.apache.org/commons/UsingNexus [2] http://commons.apache.org/releases/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Creating Project for Release Process Testing...
+1 from me for anything that makes the release process sane. I'd be committing again if preparing a release was simple enough. As it is, I don't have the blocks of time needed to push out a release and committing to projects with no apparent release manager becomes an exercise in futility. Hen On Thu, Oct 10, 2013 at 8:24 AM, James Carman wrote: > Why don't we create a real project that we can cut real releases on to > test our release procedures? Perhaps we can set it up so that it > doesn't sync with central and just gets staged locally. This way, we > can test out changes to the release process and see how they work. > Also, a new release manager can play around with that project and get > it right before diving into the real work. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [DISCUSS] Creating Project for Release Process Testing...
On 2013-10-11, Matt Benson wrote: > We're all still talking about the release process, but in all honesty I've > not done it for several years at Commons. I think it would be immensely > helpful for those of us who have been at least part way through the process > fairly recently (Emmanuel, Gary, others?) to present your recollections of > what was difficult, so that we can have a real list of things to try and > address. Not sure whether May is recent enough :-) AFAIR there isn't anything difficult. The major pain point for me is the sheer number of manual steps - with it comes a big number of opportunities to make mistakes - and the time it takes. One detail I just figured out after my third release was that I can start the gpg-agent before running "mvn deploy" - and I think I've documented that. Without that I had to type in my passphrase for every single artifact. I prefer the "create the tag manually and avoid the release plugin" approach but don't think there is a big difference here. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Creating Project for Release Process Testing...
We're all still talking about the release process, but in all honesty I've not done it for several years at Commons. I think it would be immensely helpful for those of us who have been at least part way through the process fairly recently (Emmanuel, Gary, others?) to present your recollections of what was difficult, so that we can have a real list of things to try and address. Matt On Thu, Oct 10, 2013 at 10:46 AM, James Carman wrote: > I need to have Matt start writing my emails. What he said! ;) I'm too > impatient to be so eloquent. > > On Thu, Oct 10, 2013 at 11:41 AM, Matt Benson > wrote: > > Emmanuel, > > IMO this goes beyond the SCM question. Commons releases are painful > > (you've just been through the process; do you disagree?) and I submit > that > > this fact is the reason it takes so long for any of us to muster up the > > courage to commit himself to diving into that process with no real idea > > when he'll emerge. Such a project would allow us to generalize and work > > out the various "parts" that might be relevant to any Commons project and > > could then serve as a cookbook to show how to address various situations. > > > > Matt > > > > > > On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg > wrote: > > > >> Le 10/10/2013 17:24, James Carman a écrit : > >> > Why don't we create a real project that we can cut real releases on to > >> > test our release procedures? Perhaps we can set it up so that it > >> > doesn't sync with central and just gets staged locally. This way, we > >> > can test out changes to the release process and see how they work. > >> > Also, a new release manager can play around with that project and get > >> > it right before diving into the real work. > >> > >> I'm not sure to see the need for this. There is no doubt Git is suitable > >> for releasing our components. I just walked down the release process for > >> JCI and besides for tagging I didn't have to interact much with SVN (I > >> didn't use the Maven release plugin). > >> > >> With Git you would just have to create a branch, and push a commit that > >> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is > >> the same. > >> > >> Emmanuel Bourg > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> >
Re: [DISCUSS] Creating Project for Release Process Testing...
I need to have Matt start writing my emails. What he said! ;) I'm too impatient to be so eloquent. On Thu, Oct 10, 2013 at 11:41 AM, Matt Benson wrote: > Emmanuel, > IMO this goes beyond the SCM question. Commons releases are painful > (you've just been through the process; do you disagree?) and I submit that > this fact is the reason it takes so long for any of us to muster up the > courage to commit himself to diving into that process with no real idea > when he'll emerge. Such a project would allow us to generalize and work > out the various "parts" that might be relevant to any Commons project and > could then serve as a cookbook to show how to address various situations. > > Matt > > > On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg wrote: > >> Le 10/10/2013 17:24, James Carman a écrit : >> > Why don't we create a real project that we can cut real releases on to >> > test our release procedures? Perhaps we can set it up so that it >> > doesn't sync with central and just gets staged locally. This way, we >> > can test out changes to the release process and see how they work. >> > Also, a new release manager can play around with that project and get >> > it right before diving into the real work. >> >> I'm not sure to see the need for this. There is no doubt Git is suitable >> for releasing our components. I just walked down the release process for >> JCI and besides for tagging I didn't have to interact much with SVN (I >> didn't use the Maven release plugin). >> >> With Git you would just have to create a branch, and push a commit that >> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is >> the same. >> >> Emmanuel Bourg >> >> >> - >> 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
Re: [DISCUSS] Creating Project for Release Process Testing...
Or just a multi-module only and do the worst case scenario. On Thu, Oct 10, 2013 at 11:41 AM, Emmanuel Bourg wrote: > Le 10/10/2013 17:36, James Carman a écrit : >> This isn't to address Git. This is just in-general a little sandbox >> that folks can use to either test out change to the release process >> (or documentation) or just have a go at being a release manager before >> actually volunteering. Anyone would be free to cut a release at any >> time. > > Ah sure, excellent idea. You may want two projects then, a simple one > and another with modules. > > Emmanuel Bourg > > > - > 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
Re: [DISCUSS] Creating Project for Release Process Testing...
Le 10/10/2013 17:36, James Carman a écrit : > This isn't to address Git. This is just in-general a little sandbox > that folks can use to either test out change to the release process > (or documentation) or just have a go at being a release manager before > actually volunteering. Anyone would be free to cut a release at any > time. Ah sure, excellent idea. You may want two projects then, a simple one and another with modules. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Creating Project for Release Process Testing...
Emmanuel, IMO this goes beyond the SCM question. Commons releases are painful (you've just been through the process; do you disagree?) and I submit that this fact is the reason it takes so long for any of us to muster up the courage to commit himself to diving into that process with no real idea when he'll emerge. Such a project would allow us to generalize and work out the various "parts" that might be relevant to any Commons project and could then serve as a cookbook to show how to address various situations. Matt On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg wrote: > Le 10/10/2013 17:24, James Carman a écrit : > > Why don't we create a real project that we can cut real releases on to > > test our release procedures? Perhaps we can set it up so that it > > doesn't sync with central and just gets staged locally. This way, we > > can test out changes to the release process and see how they work. > > Also, a new release manager can play around with that project and get > > it right before diving into the real work. > > I'm not sure to see the need for this. There is no doubt Git is suitable > for releasing our components. I just walked down the release process for > JCI and besides for tagging I didn't have to interact much with SVN (I > didn't use the Maven release plugin). > > With Git you would just have to create a branch, and push a commit that > changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is > the same. > > Emmanuel Bourg > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [DISCUSS] Creating Project for Release Process Testing...
This isn't to address Git. This is just in-general a little sandbox that folks can use to either test out change to the release process (or documentation) or just have a go at being a release manager before actually volunteering. Anyone would be free to cut a release at any time. On Thu, Oct 10, 2013 at 11:34 AM, Emmanuel Bourg wrote: > Le 10/10/2013 17:24, James Carman a écrit : >> Why don't we create a real project that we can cut real releases on to >> test our release procedures? Perhaps we can set it up so that it >> doesn't sync with central and just gets staged locally. This way, we >> can test out changes to the release process and see how they work. >> Also, a new release manager can play around with that project and get >> it right before diving into the real work. > > I'm not sure to see the need for this. There is no doubt Git is suitable > for releasing our components. I just walked down the release process for > JCI and besides for tagging I didn't have to interact much with SVN (I > didn't use the Maven release plugin). > > With Git you would just have to create a branch, and push a commit that > changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is > the same. > > Emmanuel Bourg > > > - > 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
Re: [DISCUSS] Creating Project for Release Process Testing...
Le 10/10/2013 17:24, James Carman a écrit : > Why don't we create a real project that we can cut real releases on to > test our release procedures? Perhaps we can set it up so that it > doesn't sync with central and just gets staged locally. This way, we > can test out changes to the release process and see how they work. > Also, a new release manager can play around with that project and get > it right before diving into the real work. I'm not sure to see the need for this. There is no doubt Git is suitable for releasing our components. I just walked down the release process for JCI and besides for tagging I didn't have to interact much with SVN (I didn't use the Maven release plugin). With Git you would just have to create a branch, and push a commit that changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is the same. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Creating Project for Release Process Testing...
Fine with me! I'm good with that. I just was worried folks would think of it as "cluttering" central On Thu, Oct 10, 2013 at 11:29 AM, Gary Gregory wrote: > Nice idea, but push it to central to test the whole chain. > > G > > On Thu, Oct 10, 2013 at 11:24 AM, James Carman > wrote: >> Why don't we create a real project that we can cut real releases on to >> test our release procedures? Perhaps we can set it up so that it >> doesn't sync with central and just gets staged locally. This way, we >> can test out changes to the release process and see how they work. >> Also, a new release manager can play around with that project and get >> it right before diving into the real work. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > 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
Re: [DISCUSS] Creating Project for Release Process Testing...
Once it's properly in Nexus, is there any reason to push all the way to central? Matt On Thu, Oct 10, 2013 at 10:29 AM, Gary Gregory wrote: > Nice idea, but push it to central to test the whole chain. > > G > > On Thu, Oct 10, 2013 at 11:24 AM, James Carman > wrote: > > Why don't we create a real project that we can cut real releases on to > > test our release procedures? Perhaps we can set it up so that it > > doesn't sync with central and just gets staged locally. This way, we > > can test out changes to the release process and see how they work. > > Also, a new release manager can play around with that project and get > > it right before diving into the real work. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [DISCUSS] Creating Project for Release Process Testing...
Nice idea, but push it to central to test the whole chain. G On Thu, Oct 10, 2013 at 11:24 AM, James Carman wrote: > Why don't we create a real project that we can cut real releases on to > test our release procedures? Perhaps we can set it up so that it > doesn't sync with central and just gets staged locally. This way, we > can test out changes to the release process and see how they work. > Also, a new release manager can play around with that project and get > it right before diving into the real work. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
