On 6/22/13 7:26 AM, Mark Thomas wrote: > On 22/06/2013 14:45, Gary Gregory wrote: >> I'm for whatever does the RM process easier and less error prone. If >> that means maven plugins, so be it. > This is written as someone who has never released a commons component > and is very grateful for the folks that have done the release work for > the components he has been involved in. > > I see various messages indicating how hard / complex / tricky / easy to > get wrong doing a release is. The frequency of the messages does not > appear to have changed significantly over time and they have been sent > but both newcomers to the project and folks that were here long before I > was. > > I can't help but think that we must be doing something wrong. The Tomcat > release process is a breeze. It takes me about 2 minutes actual work. It > takes longer to upload the release artifacts for voting. And I spend > even longer making sure I am happy with what I am about to tag. > > The obvious difference is that Tomcat is primarily an Ant based release > process with a little bit of Maven to talk to Nexus whereas the Commons > releases are primarily (wholly?) Maven based. However, I can't believe > that this is a tools issue. If everyone found Maven this hard to release > software with, no-one would be using it and it is clearly popular. That > begs the question: what are we doing wrong? Why do releases appear to be > much more difficult than they should be? > > I don't have answers neither do I have the Maven knowledge I suspect is > necessary to figure the answers out. I encourage those that do have the > Maven skills to put on their thinking caps.
+1 I think that is what sebb and others have been doing working on build plugins. Lets agree on a simple way to make these plugins available, get them really working, document their use and then enjoy the stability :) So in the spirit of removing barriers, I would like to propose the following: 0) We designate a new class of commons components, called "commons RM" or "commons-plugins." These things do not have web sites and are not otherwise advertised or promoted for use outside of Commons. Their sole purpose is to help Commons release managers prepare and manipulate release candidates. Their use should *not* be required to execute the basic maven goals involved with building the software - i.e., "mvn jar" and "mvn install" should work without them. In other words, users should be able to build from source tags without them. 1) [RM] components can be released at any time via lazy consensus VOTE, as we do now for commons parent. 2) RMs agree to collectively maintain these components and update /releases so that the directions there work with currently released versions of the [RM] plugins. To get to windows of stability for the components I have released, I have always resorted to custom bash scripts, which have worked fine for me, but I understand a) not all RMs run unix b) we should be trying to limit the things requiring shell access and c) uncoordinated per-component scripts tend to break. The advantage of sebb's approach is that (like what the Tomcat Ant scripts do) it eliminates the need for command-line scripting to create and manage RCs. With all of the maven expertise we have here, we should be able to get something working that meets the needs of at least most active Commons components. Lets not get tied up in release mechanics for the tools to make releases easier :) Phil > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
