Yes +1 to XXX-Next. I really don't like making unnecessary 'rules' or policy or trying to restrict or control who can do something. If we can't find a less relaxed way to do this then I'd prefer to just not include the JIRA list in the release notes. Couldn't it just be whoever adds the jira list to the release notes checks the list is correct and that will also be validated during everyones review of the release?
...ant On 5/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
I think using XXX-Next seems more appropriate now, that we are going out of milestone releases. As for the JIRA process, I think that Kevin's original proposal seems good and would be consistent no matter witch phase of development/release we are, it also leaves room to the Release Manager to control the open issues, like Ant suggested, as the RM can start moving open issues to a specific "fix version" when approaching the release time. As for Release process, some info available at [1] and we could probably make it more generic to be a Tuscany release process. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Release+Process On 5/22/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > I think my proposal is consistent with your desire to get the overview. > When entering the new release phase, all JIRAs fixed in the period since > the last release would be reclassified to the newly created version tag, > along with all JIRAs that the community sees as important for the > forthcoming release. > > However, an alternative rule of thumb would be that its always safe to use > the *Next version as the fix version, whether raising or resolving a JIRA. > Only use a specific version if you really are sure that either the > resolution of the defect is a blocker for a release or that the fix you > have > committed will definitely make it into a release. I just liked the > simplicity of my original proposal. > > Kelvin > > On 22/05/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > One of the problems with not assigning the specific fix version to > JIRA's > > till the end is that you can't see whats outstanding from the JIRA > overview > > page which is something I've found useful and have used it in past > releases > > to manage what things need to get done. See > > http://issues.apache.org/jira/browse/TUSCANY > > > > Maybe just more knowledge about how the versions get used would be > enough? > > > > ...ant > > > > On 5/22/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > > > Java SDO has been doing this using an Java-SDO-Mx release rather than > > > Java-SDO-Next, but as I said on IRC I think the Next naming is much > > > better. > > > > > > I propose that we adopt the policy that no-one other than a release > > > manager > > > ever assigns anything other than a *Next value for the fix release of > a > > > JIRA. > > > > > > The reason I say this is that it makes it simpler around the time of > the > > > release. I noted that at the time of the recent SDO release a couple > of > > > > > > JIRAs got closed with a fix-version of beta1 after the last release > > > candidate had been cut, but before the beta1 had been released. As > > > there > > > is this time of uncertainty I think its far better to leave the job of > > > assigning a real fix-release value to a JIRA. Its easy for the RM to > do > > > a > > > bulk change on all *Next jiras at the appropriate time to whatever the > > > real > > > release becomes know as. > > > > > > Regards, Kelvin. > > > > > > On 21/05/07, haleh mahbod < [EMAIL PROTECTED]> wrote: > > > > > > > > It would be good if all subprojects used whatever scheme it is > agreed > > > to > > > > so > > > > a developer going across projects does not have to think about > > > adjusting. > > > > > > > > > > > > On 5/21/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > > > This time round, as so much had changed, we didn't include JIRA > > > numbers > > > > in > > > > > the release docs. It seems like a good thing to do in the future > > > though. > > > > > If > > > > > everyone agrees that this is a good thing we need to be fairly > > > organized > > > > > about how we use JIRA otherwise we suffer a lot of pain come > release > > > > > > > time > > > > > working out what the list should look like. > > > > > > > > > > So, from the IRC today, it has been suggested that we take care to > > > note > > > > > what > > > > > release a fix targets using the protocol that the release is > > > > > "Java-SCA-Next" > > > > > until we get to release time and decide what the release number > is. > > > At > > > > > that > > > > > point we switch over all the fixes that make the release to the > > > right > > > > > number. > > > > > > > > > > This may well have been the intention all along as I note that the > > > > > "Java-SCA-Next category has a lot of fixes in it. I'll take a look > > > > through > > > > > it and see if I can work out what the state of play is so we can > > > start > > > > > filling it up again. > > > > > > > > > > Anything else we should be doing with respect to JIRA to make the > > > > release > > > > > process easier? > > > > > > > > > > Simon > > > > > > > > > > > > > > > > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
