Am 22.06.2013 19:10, schrieb Gary Gregory:
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.
+1 from me, too. This seems to be a good approach.
Coming back to sebb's original proposal to access the plug-ins from a
local maven repository: Would it be possible to integrate them (and our
whole release process) into a CI environment? For instance, there could
be Jenkins jobs that build and deploy an RC so that it is ready for a
vote. Then RMs don't have do any local setup.
Oliver
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
