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
>

Reply via email to