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 > 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
