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-unsubscr...@commons.apache.org<javascript:;> > > For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> > >
