You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/05/21 18:27:05 UTC
Java SCA - Including fix numbers in release docs
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
Re: Java SCA - Including fix numbers in release docs
Posted by Simon Laws <si...@googlemail.com>.
OK, I agree. I note that SDO already does this. Any more thoughts about
things we can do to improve the way we can all work in this area? What else
do SDO, DAS do that SCA needs to do? Maybe we can come up with a checklist
for the build and release up on the developer guide section of the web site.
I know Kelvin started collecting this information for SDO but can't lay my
finger on it directly.
Simon
Re: Java SCA - Including fix numbers in release docs
Posted by Luciano Resende <lu...@gmail.com>.
I agree with Haleh, we should try to have consistence on areas common to all
Tuscany sub-projects, JIRA, Distributions, Release Process, etc
On 5/21/07, haleh mahbod <hm...@gmail.com> 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 <si...@googlemail.com> 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/
Re: Java SCA - Including fix numbers in release docs
Posted by Simon Laws <si...@googlemail.com>.
+1 XXX-Next
I don't mind who assigns JIRA to the release number. It can't be done though
until we know that the release number will be (was quite late in the last
cycle). Hopefully we will do more frequent releases from now so there will
be few JIRAs in the XXX-Next box and more with the actual release tag.
Simon
Re: Java SCA - Including fix numbers in release docs
Posted by Luciano Resende <lu...@gmail.com>.
Just adding a little caveat here, that, only Resolved jiras can be
bulk updated later on (when a release is approaching), jiras on the
closed as fixed state need to be reopened in order to get edited. If
we are going to use bulk updates, we should make everybody resolve the
jiras, instead of closing them.
PS.: If someone knows a way to bulk edit a closed jira, please let me know.
On 5/23/07, kelvin goodson <ke...@gmail.com> wrote:
> > I really don't like making unnecessary 'rules' or policy or trying to
> > restrict or control who can do something
>
>
> I think you are probably right, that's why I suggested the alternative rule
> of thumb, which is nothing more than common sense really. I think the
> important thing is instilling an understanding that the field will be used
> at release time and therefore its helpful to do the right thing with it.
>
> 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?
>
>
> Sure, but in the absence of certainty about the fix-release field accuracy
> the query that the RM must use would probably be based on the fixes that
> occurred between the revision numbers for when the branches and tags of the
> previous and current releases were cut, taking into account any porting of
> fixes between trunk/branch/tag after their creation. It works, I'm sure,
> it's just harder work :-(
>
> Kelvin.
>
> ...ant
> >
> > On 5/22/07, Luciano Resende < luckbr1975@gmail.com> 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 < kelvin@thegoodsons.org.uk> 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 <an...@gmail.com> 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 < kelvingoodson@gmail.com> 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 < hmahbod@gmail.com> 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 <si...@googlemail.com> 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://people.apache.org/%7Elresende>
> > > http://lresende.blogspot.com/
> > >
> >
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java SCA - Including fix numbers in release docs
Posted by kelvin goodson <ke...@gmail.com>.
> I really don't like making unnecessary 'rules' or policy or trying to
> restrict or control who can do something
I think you are probably right, that's why I suggested the alternative rule
of thumb, which is nothing more than common sense really. I think the
important thing is instilling an understanding that the field will be used
at release time and therefore its helpful to do the right thing with it.
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?
Sure, but in the absence of certainty about the fix-release field accuracy
the query that the RM must use would probably be based on the fixes that
occurred between the revision numbers for when the branches and tags of the
previous and current releases were cut, taking into account any porting of
fixes between trunk/branch/tag after their creation. It works, I'm sure,
it's just harder work :-(
Kelvin.
...ant
>
> On 5/22/07, Luciano Resende < luckbr1975@gmail.com> 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 < kelvin@thegoodsons.org.uk> 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 <an...@gmail.com> 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 < kelvingoodson@gmail.com> 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 < hmahbod@gmail.com> 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 <si...@googlemail.com> 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://people.apache.org/%7Elresende>
> > http://lresende.blogspot.com/
> >
>
Re: Java SCA - Including fix numbers in release docs
Posted by ant elder <an...@gmail.com>.
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 <lu...@gmail.com> 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 <ke...@thegoodsons.org.uk> 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 <an...@gmail.com> 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 <ke...@gmail.com> 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 < hmahbod@gmail.com> 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 <si...@googlemail.com> 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/
>
Re: Java SCA - Including fix numbers in release docs
Posted by Luciano Resende <lu...@gmail.com>.
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 <ke...@thegoodsons.org.uk> 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 <an...@gmail.com> 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 <ke...@gmail.com> 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 < hmahbod@gmail.com> 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 <si...@googlemail.com> 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/
Re: Java SCA - Including fix numbers in release docs
Posted by kelvin goodson <ke...@thegoodsons.org.uk>.
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 <an...@gmail.com> 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 <ke...@gmail.com> 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 < hmahbod@gmail.com> 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 <si...@googlemail.com> 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
> > > >
> > >
> >
>
>
Re: Java SCA - Including fix numbers in release docs
Posted by ant elder <an...@gmail.com>.
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 <ke...@gmail.com> 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 <hm...@gmail.com> 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 <si...@googlemail.com> 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
> > >
> >
>
Re: Java SCA - Including fix numbers in release docs
Posted by kelvin goodson <ke...@gmail.com>.
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 <hm...@gmail.com> 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 <si...@googlemail.com> 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
> >
>
Re: Java SCA - Including fix numbers in release docs
Posted by haleh mahbod <hm...@gmail.com>.
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 <si...@googlemail.com> 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
>