commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [DISCUSS] Creating Project for Release Process Testing...
Date Sun, 13 Oct 2013 17:19:43 GMT
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:
> 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.



>  * removing spurious files from Nexus is a pain after a few RCs
> Regards,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message