You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Kevin Menard <km...@servprise.com> on 2007/02/13 17:58:57 UTC
JIRA changelog & roadmap
In my own work, I've found the JIRA changelog & roadmap features to be
very helpful. It makes it very easy to see what each version actually
fixed and gives a good idea as to what the next version will fix.
Unfortunately, we just lump everything into major.minor. So, it's not
really easy to tell what was fixed in 2.0, 2.0.1, and 2.0.2. If we can
get some sort of lazy concensus on this, I'd like to see someone with
administrative rights ad new minor versions to the project and I'll
volunteer to update the appropriate fix versions for the issues.
--
Kevin
Kevin Menard
Servprise International, Inc.
800.832.3823 x308
Re: JIRA changelog & roadmap
Posted by Mike Kienenberger <mk...@gmail.com>.
+1
On 2/15/07, Michael Gentry <bl...@gmail.com> wrote:
> I'm pretty lazy right now (as in other things occupying time), but it
> sounds like a good idea -- especially if it can help generate the
> release notes. So, I'd say +1 especially if the pulldown list doesn't
> get all cluttered with the "archived" versions.
>
> /dev/mrg
>
>
> On 2/14/07, Andrus Adamchik <an...@objectstyle.org> wrote:
> > Sure, lets wait for another day or two to establish lazy consensus.
> >
> > Andrus
> >
> >
> > On Feb 13, 2007, at 11:23 PM, Kevin Menard wrote:
> >
> > > Should we wait for others to chime in before making the change?
> > >
> > > --
> > > Kevin
> > >
> > >> -----Original Message-----
> > >> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> > >> Sent: Tuesday, February 13, 2007 3:06 PM
> > >> To: dev@cayenne.apache.org
> > >> Subject: Re: JIRA changelog & roadmap
> > >>
> > >> Even better :-)
> > >>
> > >> I just added your id to Cayenne project admins in Jira. Let
> > >> me know if this wasn't enough to edit the versions.
> > >>
> > >> Andrus
> > >>
> > >>
> > >> On Feb 13, 2007, at 3:00 PM, Kevin Menard wrote:
> > >>
> > >>> I think once you "archive" a version it's no longer
> > >> selectable in any
> > >>> of the issue filings. For instance, we'd probably archive
> > >> 1.2, 1.2.1,
> > >>> 2.0, and 2.0.1, so they could not be selected as "affects" or "fix
> > >>> version".
> > >>> Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and
> > >>> 2.0.3
> > >>> available as fix versions. Versions that are archived still retain
> > >>> their changelogs though. So, I think that would address
> > >> your concern.
> > >>>
> > >>> I'm not sure how far back that feature goes, though, and if it's
> > >>> available in the version the ASF runs. A JIRA admin would have to
> > >>> look into that.
> > >>>
> > >>> --
> > >>> Kevin
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> > >>>> Sent: Tuesday, February 13, 2007 12:56 PM
> > >>>> To: dev@cayenne.apache.org
> > >>>> Subject: Re: JIRA changelog & roadmap
> > >>>>
> > >>>> +1
> > >>>>
> > >>>> The downside is that we'll have a very long list of versions, with
> > >>>> higher probability of making a mistake when picking one.
> > >>>> But the upside (at least I hope) will be that the
> > >> RELEASE-NOTES can
> > >>>> be generated straight from Jira, regardless how many versions a
> > >>>> particular fix affected (currently the RELEASE-NOTES.txt is built
> > >>>> manually).
> > >>>>
> > >>>> Andrus
> > >>>
> > >>
> > >>
> > >
> >
> >
>
Re: JIRA changelog & roadmap
Posted by Michael Gentry <bl...@gmail.com>.
I'm pretty lazy right now (as in other things occupying time), but it
sounds like a good idea -- especially if it can help generate the
release notes. So, I'd say +1 especially if the pulldown list doesn't
get all cluttered with the "archived" versions.
/dev/mrg
On 2/14/07, Andrus Adamchik <an...@objectstyle.org> wrote:
> Sure, lets wait for another day or two to establish lazy consensus.
>
> Andrus
>
>
> On Feb 13, 2007, at 11:23 PM, Kevin Menard wrote:
>
> > Should we wait for others to chime in before making the change?
> >
> > --
> > Kevin
> >
> >> -----Original Message-----
> >> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> >> Sent: Tuesday, February 13, 2007 3:06 PM
> >> To: dev@cayenne.apache.org
> >> Subject: Re: JIRA changelog & roadmap
> >>
> >> Even better :-)
> >>
> >> I just added your id to Cayenne project admins in Jira. Let
> >> me know if this wasn't enough to edit the versions.
> >>
> >> Andrus
> >>
> >>
> >> On Feb 13, 2007, at 3:00 PM, Kevin Menard wrote:
> >>
> >>> I think once you "archive" a version it's no longer
> >> selectable in any
> >>> of the issue filings. For instance, we'd probably archive
> >> 1.2, 1.2.1,
> >>> 2.0, and 2.0.1, so they could not be selected as "affects" or "fix
> >>> version".
> >>> Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and
> >>> 2.0.3
> >>> available as fix versions. Versions that are archived still retain
> >>> their changelogs though. So, I think that would address
> >> your concern.
> >>>
> >>> I'm not sure how far back that feature goes, though, and if it's
> >>> available in the version the ASF runs. A JIRA admin would have to
> >>> look into that.
> >>>
> >>> --
> >>> Kevin
> >>>
> >>>> -----Original Message-----
> >>>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> >>>> Sent: Tuesday, February 13, 2007 12:56 PM
> >>>> To: dev@cayenne.apache.org
> >>>> Subject: Re: JIRA changelog & roadmap
> >>>>
> >>>> +1
> >>>>
> >>>> The downside is that we'll have a very long list of versions, with
> >>>> higher probability of making a mistake when picking one.
> >>>> But the upside (at least I hope) will be that the
> >> RELEASE-NOTES can
> >>>> be generated straight from Jira, regardless how many versions a
> >>>> particular fix affected (currently the RELEASE-NOTES.txt is built
> >>>> manually).
> >>>>
> >>>> Andrus
> >>>
> >>
> >>
> >
>
>
Re: JIRA changelog & roadmap
Posted by Andrus Adamchik <an...@objectstyle.org>.
Sure, lets wait for another day or two to establish lazy consensus.
Andrus
On Feb 13, 2007, at 11:23 PM, Kevin Menard wrote:
> Should we wait for others to chime in before making the change?
>
> --
> Kevin
>
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> Sent: Tuesday, February 13, 2007 3:06 PM
>> To: dev@cayenne.apache.org
>> Subject: Re: JIRA changelog & roadmap
>>
>> Even better :-)
>>
>> I just added your id to Cayenne project admins in Jira. Let
>> me know if this wasn't enough to edit the versions.
>>
>> Andrus
>>
>>
>> On Feb 13, 2007, at 3:00 PM, Kevin Menard wrote:
>>
>>> I think once you "archive" a version it's no longer
>> selectable in any
>>> of the issue filings. For instance, we'd probably archive
>> 1.2, 1.2.1,
>>> 2.0, and 2.0.1, so they could not be selected as "affects" or "fix
>>> version".
>>> Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and
>>> 2.0.3
>>> available as fix versions. Versions that are archived still retain
>>> their changelogs though. So, I think that would address
>> your concern.
>>>
>>> I'm not sure how far back that feature goes, though, and if it's
>>> available in the version the ASF runs. A JIRA admin would have to
>>> look into that.
>>>
>>> --
>>> Kevin
>>>
>>>> -----Original Message-----
>>>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>>>> Sent: Tuesday, February 13, 2007 12:56 PM
>>>> To: dev@cayenne.apache.org
>>>> Subject: Re: JIRA changelog & roadmap
>>>>
>>>> +1
>>>>
>>>> The downside is that we'll have a very long list of versions, with
>>>> higher probability of making a mistake when picking one.
>>>> But the upside (at least I hope) will be that the
>> RELEASE-NOTES can
>>>> be generated straight from Jira, regardless how many versions a
>>>> particular fix affected (currently the RELEASE-NOTES.txt is built
>>>> manually).
>>>>
>>>> Andrus
>>>
>>
>>
>
RE: JIRA changelog & roadmap
Posted by Kevin Menard <km...@servprise.com>.
Should we wait for others to chime in before making the change?
--
Kevin
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Tuesday, February 13, 2007 3:06 PM
> To: dev@cayenne.apache.org
> Subject: Re: JIRA changelog & roadmap
>
> Even better :-)
>
> I just added your id to Cayenne project admins in Jira. Let
> me know if this wasn't enough to edit the versions.
>
> Andrus
>
>
> On Feb 13, 2007, at 3:00 PM, Kevin Menard wrote:
>
> > I think once you "archive" a version it's no longer
> selectable in any
> > of the issue filings. For instance, we'd probably archive
> 1.2, 1.2.1,
> > 2.0, and 2.0.1, so they could not be selected as "affects" or "fix
> > version".
> > Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and
> > 2.0.3
> > available as fix versions. Versions that are archived still retain
> > their changelogs though. So, I think that would address
> your concern.
> >
> > I'm not sure how far back that feature goes, though, and if it's
> > available in the version the ASF runs. A JIRA admin would have to
> > look into that.
> >
> > --
> > Kevin
> >
> >> -----Original Message-----
> >> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> >> Sent: Tuesday, February 13, 2007 12:56 PM
> >> To: dev@cayenne.apache.org
> >> Subject: Re: JIRA changelog & roadmap
> >>
> >> +1
> >>
> >> The downside is that we'll have a very long list of versions, with
> >> higher probability of making a mistake when picking one.
> >> But the upside (at least I hope) will be that the
> RELEASE-NOTES can
> >> be generated straight from Jira, regardless how many versions a
> >> particular fix affected (currently the RELEASE-NOTES.txt is built
> >> manually).
> >>
> >> Andrus
> >
>
>
Re: JIRA changelog & roadmap
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Feb 17, 2007, at 11:38 AM, Kevin Menard wrote:
> I only have "Transition Issues" and "Delete
> Issues" available to me . . .
Just tried - me too.
Andrus
RE: JIRA changelog & roadmap
Posted by Kevin Menard <km...@servprise.com>.
Actually, looking again, I may just lack permissions.
Andrus, can you bulk edit closed issues? You can verify by clicking
the "closed" link from the main Cayenne JIRA page. Then in the
upper-right, click the "all 592 issue(s)" next to the "Bulk Change"
label. Select a few issues, click "Next". Then check if you can "Edit
Issues" in the next step. I only have "Transition Issues" and "Delete
Issues" available to me . . .
If you can actually edit issues, we may not need to get the infra guys
involved at all.
Thanks,
Kevin
> -----Original Message-----
> From: Kevin Menard [mailto:kmenard@servprise.com]
> Sent: Saturday, February 17, 2007 11:32 AM
> To: dev@cayenne.apache.org
> Subject: RE: JIRA changelog & roadmap
>
> Okay, this is actually a bit more complicated than I had
> hoped. The issue is that the workflow used by the ASF JIRA
> does not allow for bulk editing for closed issues. So, our
> three options are:
>
> 1) Say forget it.
> 2) Re-open the "incorrect" closed issues and then close them
> again with the new fix version.
> 3) Request the infra folks involved to modify or create a new
> workflow per [1].
>
> I'm still a fan of the change, but it appears I'm the only
> one to have complained thus far, so 1) may be a viable
> option. 2) we can do on our own. We'll just see a temporary
> flood of email as the issues are opened and then closed
> (maybe about 20 total). 3) seems like a better long term
> solution, but requires outside assistance that may not be granted.
>
> Thoughts?
>
> [1]
> http://www.atlassian.com/software/jira/docs/latest/workflow.ht
> ml#unedita
> ble_steps
>
> --
> Kevin
>
> > -----Original Message-----
> > From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> > Sent: Tuesday, February 13, 2007 3:06 PM
> > To: dev@cayenne.apache.org
> > Subject: Re: JIRA changelog & roadmap
> >
> > Even better :-)
> >
> > I just added your id to Cayenne project admins in Jira. Let
> me know if
> > this wasn't enough to edit the versions.
> >
> > Andrus
> >
> >
> > On Feb 13, 2007, at 3:00 PM, Kevin Menard wrote:
> >
> > > I think once you "archive" a version it's no longer
> > selectable in any
> > > of the issue filings. For instance, we'd probably archive
> > 1.2, 1.2.1,
> > > 2.0, and 2.0.1, so they could not be selected as
> "affects" or "fix
> > > version".
> > > Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and
> > > 2.0.3
> > > available as fix versions. Versions that are archived
> still retain
> > > their changelogs though. So, I think that would address
> > your concern.
> > >
> > > I'm not sure how far back that feature goes, though, and if it's
> > > available in the version the ASF runs. A JIRA admin
> would have to
> > > look into that.
> > >
> > > --
> > > Kevin
> > >
> > >> -----Original Message-----
> > >> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> > >> Sent: Tuesday, February 13, 2007 12:56 PM
> > >> To: dev@cayenne.apache.org
> > >> Subject: Re: JIRA changelog & roadmap
> > >>
> > >> +1
> > >>
> > >> The downside is that we'll have a very long list of
> versions, with
> > >> higher probability of making a mistake when picking one.
> > >> But the upside (at least I hope) will be that the
> > RELEASE-NOTES can
> > >> be generated straight from Jira, regardless how many versions a
> > >> particular fix affected (currently the RELEASE-NOTES.txt
> is built
> > >> manually).
> > >>
> > >> Andrus
> > >
> >
> >
>
Re: Planning Releases [WAS: JIRA changelog & roadmap]
Posted by Craig L Russell <Cr...@Sun.COM>.
On Feb 17, 2007, at 10:54 AM, Andrus Adamchik wrote:
>
> On Feb 17, 2007, at 11:59 AM, Kevin Menard wrote:
>
>> Fair enough. What I was hoping to achieve was some idea of when
>> to cut
>> a release. Right now we sorta just wing it. When enough issues are
>> closed someone proposes the vote and we go from there. What might be
>> nice is knowing what open issues need to be fixed before we release
>> 2.0.3 and what can wait until a 2.0.4.
>
> From experience I am skeptical about that. We sort of tried this
> before, and it never really worked because of the volunteer nature
> of the project. The most honest thing to do would be to leave "Fix
> Version" blank, until the fix is actually ready to be committed.
That's been my experience as well with open source projects. Winging
it might not be the best for users but seems to work in practice. And
anyone who really really really wants a bug fixed can volunteer to
fix it.
Craig
>
> Currently we may set it to "3.0", which is vague enough to give us
> breathing space. Presetting it to 3.0M1 or anything as specific
> will be too optimistic and in most cases - misleading.
>
> Andrus
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Planning Releases [WAS: JIRA changelog & roadmap]
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Feb 17, 2007, at 11:59 AM, Kevin Menard wrote:
> Fair enough. What I was hoping to achieve was some idea of when to
> cut
> a release. Right now we sorta just wing it. When enough issues are
> closed someone proposes the vote and we go from there. What might be
> nice is knowing what open issues need to be fixed before we release
> 2.0.3 and what can wait until a 2.0.4.
From experience I am skeptical about that. We sort of tried this
before, and it never really worked because of the volunteer nature of
the project. The most honest thing to do would be to leave "Fix
Version" blank, until the fix is actually ready to be committed.
Currently we may set it to "3.0", which is vague enough to give us
breathing space. Presetting it to 3.0M1 or anything as specific will
be too optimistic and in most cases - misleading.
Andrus
Planning Releases [WAS: JIRA changelog & roadmap]
Posted by Kevin Menard <km...@servprise.com>.
Fair enough. What I was hoping to achieve was some idea of when to cut
a release. Right now we sorta just wing it. When enough issues are
closed someone proposes the vote and we go from there. What might be
nice is knowing what open issues need to be fixed before we release
2.0.3 and what can wait until a 2.0.4.
I suppose we could adopt the new versions for issues going forward and
that wouldn't be terrible. Otherwise, if anyone has any ideas to fill
in that void, please pitch them.
Thanks,
Kevin
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Saturday, February 17, 2007 11:38 AM
> To: dev@cayenne.apache.org
> Subject: Re: JIRA changelog & roadmap
>
> > 1) Say forget it.
>
> +1 - all closed issues are already logged in the RELEASE-NOTES, so
> what do we care.
>
> Andrus
>
>
> On Feb 17, 2007, at 11:31 AM, Kevin Menard wrote:
>
> > Okay, this is actually a bit more complicated than I had
> hoped. The
> > issue is that the workflow used by the ASF JIRA does not allow for
> > bulk editing for closed issues. So, our three options are:
> >
> > 1) Say forget it.
> > 2) Re-open the "incorrect" closed issues and then close them again
> > with the new fix version.
> > 3) Request the infra folks involved to modify or create a
> new workflow
> > per [1].
> >
> > I'm still a fan of the change, but it appears I'm the only
> one to have
> > complained thus far, so 1) may be a viable option. 2) we can do on
> > our own. We'll just see a temporary flood of email as the
> issues are
> > opened and then closed (maybe about 20 total). 3) seems
> like a better
> > long term solution, but requires outside assistance that may not be
> > granted.
> >
> > Thoughts?
> >
> > [1]
> > http://www.atlassian.com/software/jira/docs/latest/
> > workflow.html#unedita
> > ble_steps
> >
> > --
> > Kevin
> >
> >> -----Original Message-----
> >> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> >> Sent: Tuesday, February 13, 2007 3:06 PM
> >> To: dev@cayenne.apache.org
> >> Subject: Re: JIRA changelog & roadmap
> >>
> >> Even better :-)
> >>
> >> I just added your id to Cayenne project admins in Jira.
> Let me know
> >> if this wasn't enough to edit the versions.
> >>
> >> Andrus
> >>
> >>
> >> On Feb 13, 2007, at 3:00 PM, Kevin Menard wrote:
> >>
> >>> I think once you "archive" a version it's no longer
> >> selectable in any
> >>> of the issue filings. For instance, we'd probably archive
> >> 1.2, 1.2.1,
> >>> 2.0, and 2.0.1, so they could not be selected as
> "affects" or "fix
> >>> version".
> >>> Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and
> >>> 2.0.3
> >>> available as fix versions. Versions that are archived
> still retain
> >>> their changelogs though. So, I think that would address
> >> your concern.
> >>>
> >>> I'm not sure how far back that feature goes, though, and if it's
> >>> available in the version the ASF runs. A JIRA admin
> would have to
> >>> look into that.
> >>>
> >>> --
> >>> Kevin
> >>>
> >>>> -----Original Message-----
> >>>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> >>>> Sent: Tuesday, February 13, 2007 12:56 PM
> >>>> To: dev@cayenne.apache.org
> >>>> Subject: Re: JIRA changelog & roadmap
> >>>>
> >>>> +1
> >>>>
> >>>> The downside is that we'll have a very long list of
> versions, with
> >>>> higher probability of making a mistake when picking one.
> >>>> But the upside (at least I hope) will be that the
> >> RELEASE-NOTES can
> >>>> be generated straight from Jira, regardless how many versions a
> >>>> particular fix affected (currently the RELEASE-NOTES.txt
> is built
> >>>> manually).
> >>>>
> >>>> Andrus
> >>>
> >>
> >>
> >
>
>
Re: JIRA changelog & roadmap
Posted by Andrus Adamchik <an...@objectstyle.org>.
> 1) Say forget it.
+1 - all closed issues are already logged in the RELEASE-NOTES, so
what do we care.
Andrus
On Feb 17, 2007, at 11:31 AM, Kevin Menard wrote:
> Okay, this is actually a bit more complicated than I had hoped. The
> issue is that the workflow used by the ASF JIRA does not allow for
> bulk
> editing for closed issues. So, our three options are:
>
> 1) Say forget it.
> 2) Re-open the "incorrect" closed issues and then close them again
> with
> the new fix version.
> 3) Request the infra folks involved to modify or create a new workflow
> per [1].
>
> I'm still a fan of the change, but it appears I'm the only one to have
> complained thus far, so 1) may be a viable option. 2) we can do on
> our
> own. We'll just see a temporary flood of email as the issues are
> opened
> and then closed (maybe about 20 total). 3) seems like a better long
> term solution, but requires outside assistance that may not be
> granted.
>
> Thoughts?
>
> [1]
> http://www.atlassian.com/software/jira/docs/latest/
> workflow.html#unedita
> ble_steps
>
> --
> Kevin
>
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> Sent: Tuesday, February 13, 2007 3:06 PM
>> To: dev@cayenne.apache.org
>> Subject: Re: JIRA changelog & roadmap
>>
>> Even better :-)
>>
>> I just added your id to Cayenne project admins in Jira. Let
>> me know if this wasn't enough to edit the versions.
>>
>> Andrus
>>
>>
>> On Feb 13, 2007, at 3:00 PM, Kevin Menard wrote:
>>
>>> I think once you "archive" a version it's no longer
>> selectable in any
>>> of the issue filings. For instance, we'd probably archive
>> 1.2, 1.2.1,
>>> 2.0, and 2.0.1, so they could not be selected as "affects" or "fix
>>> version".
>>> Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and
>>> 2.0.3
>>> available as fix versions. Versions that are archived still retain
>>> their changelogs though. So, I think that would address
>> your concern.
>>>
>>> I'm not sure how far back that feature goes, though, and if it's
>>> available in the version the ASF runs. A JIRA admin would have to
>>> look into that.
>>>
>>> --
>>> Kevin
>>>
>>>> -----Original Message-----
>>>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>>>> Sent: Tuesday, February 13, 2007 12:56 PM
>>>> To: dev@cayenne.apache.org
>>>> Subject: Re: JIRA changelog & roadmap
>>>>
>>>> +1
>>>>
>>>> The downside is that we'll have a very long list of versions, with
>>>> higher probability of making a mistake when picking one.
>>>> But the upside (at least I hope) will be that the
>> RELEASE-NOTES can
>>>> be generated straight from Jira, regardless how many versions a
>>>> particular fix affected (currently the RELEASE-NOTES.txt is built
>>>> manually).
>>>>
>>>> Andrus
>>>
>>
>>
>
RE: JIRA changelog & roadmap
Posted by Kevin Menard <km...@servprise.com>.
Okay, this is actually a bit more complicated than I had hoped. The
issue is that the workflow used by the ASF JIRA does not allow for bulk
editing for closed issues. So, our three options are:
1) Say forget it.
2) Re-open the "incorrect" closed issues and then close them again with
the new fix version.
3) Request the infra folks involved to modify or create a new workflow
per [1].
I'm still a fan of the change, but it appears I'm the only one to have
complained thus far, so 1) may be a viable option. 2) we can do on our
own. We'll just see a temporary flood of email as the issues are opened
and then closed (maybe about 20 total). 3) seems like a better long
term solution, but requires outside assistance that may not be granted.
Thoughts?
[1]
http://www.atlassian.com/software/jira/docs/latest/workflow.html#unedita
ble_steps
--
Kevin
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Tuesday, February 13, 2007 3:06 PM
> To: dev@cayenne.apache.org
> Subject: Re: JIRA changelog & roadmap
>
> Even better :-)
>
> I just added your id to Cayenne project admins in Jira. Let
> me know if this wasn't enough to edit the versions.
>
> Andrus
>
>
> On Feb 13, 2007, at 3:00 PM, Kevin Menard wrote:
>
> > I think once you "archive" a version it's no longer
> selectable in any
> > of the issue filings. For instance, we'd probably archive
> 1.2, 1.2.1,
> > 2.0, and 2.0.1, so they could not be selected as "affects" or "fix
> > version".
> > Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and
> > 2.0.3
> > available as fix versions. Versions that are archived still retain
> > their changelogs though. So, I think that would address
> your concern.
> >
> > I'm not sure how far back that feature goes, though, and if it's
> > available in the version the ASF runs. A JIRA admin would have to
> > look into that.
> >
> > --
> > Kevin
> >
> >> -----Original Message-----
> >> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> >> Sent: Tuesday, February 13, 2007 12:56 PM
> >> To: dev@cayenne.apache.org
> >> Subject: Re: JIRA changelog & roadmap
> >>
> >> +1
> >>
> >> The downside is that we'll have a very long list of versions, with
> >> higher probability of making a mistake when picking one.
> >> But the upside (at least I hope) will be that the
> RELEASE-NOTES can
> >> be generated straight from Jira, regardless how many versions a
> >> particular fix affected (currently the RELEASE-NOTES.txt is built
> >> manually).
> >>
> >> Andrus
> >
>
>
Re: JIRA changelog & roadmap
Posted by Andrus Adamchik <an...@objectstyle.org>.
Even better :-)
I just added your id to Cayenne project admins in Jira. Let me know
if this wasn't enough to edit the versions.
Andrus
On Feb 13, 2007, at 3:00 PM, Kevin Menard wrote:
> I think once you "archive" a version it's no longer selectable in
> any of
> the issue filings. For instance, we'd probably archive 1.2, 1.2.1,
> 2.0,
> and 2.0.1, so they could not be selected as "affects" or "fix
> version".
> Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and
> 2.0.3
> available as fix versions. Versions that are archived still retain
> their changelogs though. So, I think that would address your concern.
>
> I'm not sure how far back that feature goes, though, and if it's
> available in the version the ASF runs. A JIRA admin would have to
> look
> into that.
>
> --
> Kevin
>
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> Sent: Tuesday, February 13, 2007 12:56 PM
>> To: dev@cayenne.apache.org
>> Subject: Re: JIRA changelog & roadmap
>>
>> +1
>>
>> The downside is that we'll have a very long list of versions,
>> with higher probability of making a mistake when picking one.
>> But the upside (at least I hope) will be that the
>> RELEASE-NOTES can be generated straight from Jira, regardless
>> how many versions a particular fix affected (currently the
>> RELEASE-NOTES.txt is built manually).
>>
>> Andrus
>
RE: JIRA changelog & roadmap
Posted by Kevin Menard <km...@servprise.com>.
I think once you "archive" a version it's no longer selectable in any of
the issue filings. For instance, we'd probably archive 1.2, 1.2.1, 2.0,
and 2.0.1, so they could not be selected as "affects" or "fix version".
Bugs would then be logged against 1.2.2 and 2.0.2, with 1.2.3 and 2.0.3
available as fix versions. Versions that are archived still retain
their changelogs though. So, I think that would address your concern.
I'm not sure how far back that feature goes, though, and if it's
available in the version the ASF runs. A JIRA admin would have to look
into that.
--
Kevin
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Tuesday, February 13, 2007 12:56 PM
> To: dev@cayenne.apache.org
> Subject: Re: JIRA changelog & roadmap
>
> +1
>
> The downside is that we'll have a very long list of versions,
> with higher probability of making a mistake when picking one.
> But the upside (at least I hope) will be that the
> RELEASE-NOTES can be generated straight from Jira, regardless
> how many versions a particular fix affected (currently the
> RELEASE-NOTES.txt is built manually).
>
> Andrus
Re: JIRA changelog & roadmap
Posted by Andrus Adamchik <an...@objectstyle.org>.
+1
The downside is that we'll have a very long list of versions, with
higher probability of making a mistake when picking one. But the
upside (at least I hope) will be that the RELEASE-NOTES can be
generated straight from Jira, regardless how many versions a
particular fix affected (currently the RELEASE-NOTES.txt is built
manually).
Andrus
On Feb 13, 2007, at 11:58 AM, Kevin Menard wrote:
> In my own work, I've found the JIRA changelog & roadmap features to be
> very helpful. It makes it very easy to see what each version actually
> fixed and gives a good idea as to what the next version will fix.
>
> Unfortunately, we just lump everything into major.minor. So, it's not
> really easy to tell what was fixed in 2.0, 2.0.1, and 2.0.2. If we
> can
> get some sort of lazy concensus on this, I'd like to see someone with
> administrative rights ad new minor versions to the project and I'll
> volunteer to update the appropriate fix versions for the issues.
>
> --
> Kevin
>
> Kevin Menard
> Servprise International, Inc.
> 800.832.3823 x308
>