Coming back for thirds? I don't have a burning desire to do another release right now, but I'm happy to help (if I can).
Two things to watch out for (some of which you probably knew already) : * We should probably use the gpg maven plugin to sign all our build artifacts. Near the end of the release cycle for 0.9.7 I found out that we needed to sign everything - not just the binary jars. This is something I've been meaning to commit but I haven't gotten around to it. * The process of copying a release from a staging area to the final maven repository was a bit error prone. Jason gave me an early version of the maven staging plugin, but after a quick google / look at the maven site it didn't pop up. Maybe there's a better option available. If we get stuck I still have a copy of what Jason sent me that I can get working again. -Mike On 7/9/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
Second the motion! You did a great job last time around, and unless someone else has a burning desire to leap over the cliff with a hankie for a parachute, you're it. Craig On Jul 9, 2007, at 10:13 AM, Marc Prud'hommeaux wrote: > > >> We also need a release manager (a person who will do what Marc and >> Mike did for 0.9.6 and 0.9.7). > > Unless anyone else has a desire to do the 1.0.0 release, I'll > nominate myself, since I think I have a good idea about the things > that need to be changed in the build process to accommodate our TLP > status. > > > > On Jul 9, 2007, at 10:04 AM, Craig L Russell wrote: > >> I think we need to first go through the list of JIRA issues for >> 0.9.8 and 1.0.0 and really think hard about whether they should be >> fixed or not. >> >> We also need a release manager (a person who will do what Marc and >> Mike did for 0.9.6 and 0.9.7). >> >> Maybe we should post the list of proposed deferred JIRA issues for >> discussion and then move them. I like the idea of defining both a >> 1.0.1 and 1.1.0 release target to which to defer issues. >> >> I think once there is consensus on the non-deferred issues and an >> identified JIRA owner for them, the release manager can propose >> when to make a branch. Once the branch is cut, fixes would have to >> be made in both branch and trunk, so it's not a trivial decision. >> >> Maybe a wiki with a table of JIRA issues and proposed target >> release and some justification (with author's name) would be >> useful. It's not too hard to set up but still might not be worth >> the effort. >> >> Craig >> >> On Jul 9, 2007, at 9:50 AM, Kevin Sutter wrote: >> >>>> >>>> What is remaining to get to a 1.0 release? Are there any things in >>>> particular that people think are important to work on? Maybe it's >>>> about time for us to create a branch for 1.0 finalization and >>>> hardening. >>> >>> >>> This probably depends on what our goal is for a 1.0 release. If >>> it's just >>> to have a 1.0 release since we graduated to a TLP, then we're >>> probably close >>> to starting that process. But, if we are looking for a certain >>> level and >>> hardness of function, then we still may have a fews things to >>> clean up. I'm >>> okay with going for a 1.0 release just to have one, but I would >>> then like to >>> start working on defining the follow-on release (1.0.1 or 1.1). >>> >>> No matter what type of 1.0 release we decide to go for, maybe we >>> should >>> incorporate the voting mechanism within JIRA to help determine >>> what Issues >>> are important? I am not totally familiar with this process, but >>> it allows >>> users to vote on the Issues that are most important to them. >>> Each user is >>> allowed a certain number of votes (to keep them from voting for >>> "all" >>> Issues). We can use that as input to our selection criteria. >>> >>> But, before we open up for a vote, do we need some time to review >>> all of the >>> open Issues and assert 1.0 vs post-1.0? Something along the >>> lines of what >>> Patrick did for the previous release? I just find it kind of >>> difficult to >>> be working on various problems and then "ding", the timer goes >>> off and we've >>> cut off development for a given release. It's probably time to >>> start >>> working out a candidate release cycle and content. >>> >>> Kevin >> >> Craig Russell >> Architect, Sun Java Enterprise System http://java.sun.com/products/ >> jdo >> 408 276-5638 mailto:[EMAIL PROTECTED] >> P.S. A good JDO? O, Gasp! >> > Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
