commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [DISCUSS] Creating Project for Release Process Testing...
Date Sun, 13 Oct 2013 17:46:08 GMT
Phil, I'm for whatever makes it easier.  In the new release test project,
let's start "green field" and see what we come up with.  If we see enough
boilerplate to merit a parent, then we will extract those bits and make
one.  If not, then it's every component for themselves.

On Sunday, October 13, 2013, Phil Steitz wrote:

> 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:
> >
> >
> https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt
> >
> > 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.
>
> Phil
>
> [1]
> https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pool-RC.sh
> [2] http://markmail.org/message/kkualb7xse2mcwkd
>
> >  * removing spurious files from Nexus is a pain after a few RCs
> >
> >
> > Regards,
> > Gilles
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message