On 22 June 2013 17: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: <snip>
>> >> 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 > 1) [RM] components can be released at any time via lazy consensus > VOTE, as we do now for commons parent. +1 > 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. +1 > 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 But we still need to resolve: - where in SVN these tools belong - how to ensure the tools are readily available to RMs --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
