On Jun 22, 2013, at 12:41, Phil Steitz <phil.ste...@gmail.com> wrote:
> 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 :) +1. We can propose to graduate the plugins to Maven later when we have them good and working for our use cases. Gary > > Phil >> >> Mark >> >> --------------------------------------------------------------------- >> 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
