You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Kevin Menard <km...@servprise.com> on 2008/01/02 21:08:44 UTC
Fix versions
Is there any particular reason for that? It seems to me that if you defined
a fix version you could start using JIRA's roadmap feature. If the item
isn't resolved by the time you want to cut the release, JIRA has an easy
means of migrating all remaining issues to another fix version.
--
Kevin
On 1/2/08 2:55 PM, in article 17207629.1199303734246.JavaMail.jira@brutus,
"Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/TAPESTRY-1643?page=com.atlassian.jira.pl
> ugin.system.issuetabpanels:all-tabpanel ]
>
> Howard M. Lewis Ship updated TAPESTRY-1643:
> -------------------------------------------
>
> Fix Version/s: (was: 5.0.8)
>
> We don't define a fix version until a fix is committed.
>
>> @Mixin should accept parameters
>> -------------------------------
>>
>> Key: TAPESTRY-1643
>> URL: https://issues.apache.org/jira/browse/TAPESTRY-1643
>> Project: Tapestry
>> Issue Type: Bug
>> Components: tapestry-core
>> Affects Versions: 5.0.5
>> Reporter: Dan Adams
>>
>> With @Mixin there is no way to use a mixin that requires parameters within a
>> component. For instance if you have a Confirm mixin that has a required
>> parameter you can't use it like this:
>> @Mixin
>> private Confirm confirm;
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Fix versions
Posted by Kevin Menard <km...@servprise.com>.
On 1/3/08 9:38 AM, in article C3A25D96.A6C9%kmenard@servprise.com, "Kevin
Menard" <km...@servprise.com> wrote:
> Clearly your the project lead, so up to you.
^^^^ you're, of course.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Fix versions
Posted by Howard Lewis Ship <hl...@gmail.com>.
All valid, I don't have a master plan on this, and I may just be using
JIRA incorrectly.
On Jan 3, 2008 7:14 AM, Jesse Kuhnert <jk...@gmail.com> wrote:
> I've been bitten by the release not generator as well and decided to
> not generate release notes anymore until ~after~ I had marked the
> particular version in question as released. (and subsequently used
> the move all open issues to fix version <next> during the process)
>
> On T4 we've been using a process of trying to keep two future versions
> in jira - one for the current phase of development and one for bugs
> that we want to fix but "won't be looking at anytime soon". This
> second version is helpful for quickly deciding which general bucket
> things go in to and also helps keep the list of current version bugs
> smaller for me to browse through when deciding what to fix.
>
> No one has freaked out and complained when I moved their bugs marked
> for fix in current release to next release when they didn't make it
> in, but maybe they'll hold Howard's feet to the fire more because of
> his role in the project.
>
> Either way - he who does the work decides how the work gets done - so
> I support whatever he wants to do from that pov. ;)
>
>
> On Jan 3, 2008 9:38 AM, Kevin Menard <km...@servprise.com> wrote:
> > Clearly your the project lead, so up to you. In my experience, I've found
> > it helpful. I typically have two or three versions open and scope out the
> > work. If you want to focus on Ajax for 5.0.8, you can group all those
> > issues there and 5.0.9 can be validation clean-ups or what have you. IMHO,
> > it's nicer than just having a huge bucket of open issues that you cherry
> > pick from. It also makes it nicer for your consumers to see what the plan
> > is (it might help with all the "when is 5.0 final coming out?").
> >
> > --
> > Kevin
> >
> >
> > On 1/2/08 3:56 PM, in article
> > ecd0e3310801021256t5c172a1fje8b75706614bce6d@mail.gmail.com, "Howard Lewis
> >
> > Ship" <hl...@gmail.com> wrote:
> >
> > > The roadmap is a good idea, but I have a problem with JIRA's release
> > > note generator, since it generates a line for every bug with the
> > > release number, whether its been fixed, resolved, marked duplicate, or
> > > is still open.
> > >
> > > Roadmap is nice, but it really is about "geez, time for a release,
> > > what can we fit in?" :-)
> > >
> > > On Jan 2, 2008 12:10 PM, Jesse Kuhnert <jk...@gmail.com> wrote:
> > >> That's what I thought it was supposed to be used for..
> > >>
> > >>
> > >> On Jan 2, 2008 3:08 PM, Kevin Menard <km...@servprise.com> wrote:
> > >>> Is there any particular reason for that? It seems to me that if you defined
> > >>> a fix version you could start using JIRA's roadmap feature. If the item
> > >>> isn't resolved by the time you want to cut the release, JIRA has an easy
> > >>> means of migrating all remaining issues to another fix version.
> > >>>
> > >>> --
> > >>> Kevin
> > >>>
> > >>>
> > >>> On 1/2/08 2:55 PM, in article 17207629.1199303734246.JavaMail.jira@brutus,
> > >>> "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> wrote:
> > >>>
> > >>>>
> > >>>> [
> > >>>> https://issues.apache.org/jira/browse/TAPESTRY-1643?page=com.atlassian.jira
> > >>>> .pl
> > >>>> ugin.system.issuetabpanels:all-tabpanel ]
> > >>>>
> > >>>> Howard M. Lewis Ship updated TAPESTRY-1643:
> > >>>> -------------------------------------------
> > >>>>
> > >>>> Fix Version/s: (was: 5.0.8)
> > >>>>
> > >>>> We don't define a fix version until a fix is committed.
> > >>>>
> > >>>>> @Mixin should accept parameters
> > >>>>> -------------------------------
> > >>>>>
> > >>>>> Key: TAPESTRY-1643
> > >>>>> URL: https://issues.apache.org/jira/browse/TAPESTRY-1643
> > >>>>> Project: Tapestry
> > >>>>> Issue Type: Bug
> > >>>>> Components: tapestry-core
> > >>>>> Affects Versions: 5.0.5
> > >>>>> Reporter: Dan Adams
> > >>>>>
> > >>>>> With @Mixin there is no way to use a mixin that requires parameters within
> > >>>>> a
> > >>>>> component. For instance if you have a Confirm mixin that has a required
> > >>>>> parameter you can't use it like this:
> > >>>>> @Mixin
> > >>>>> private Confirm confirm;
> > >>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Jesse Kuhnert
> > >> Tapestry / OGNL / Dojo team member/developer
> > >>
> > >> Open source based consulting work centered around
> > >> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >>
> > >>
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
>
> --
>
> Jesse Kuhnert
> Tapestry / OGNL / Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Fix versions
Posted by Jesse Kuhnert <jk...@gmail.com>.
I've been bitten by the release not generator as well and decided to
not generate release notes anymore until ~after~ I had marked the
particular version in question as released. (and subsequently used
the move all open issues to fix version <next> during the process)
On T4 we've been using a process of trying to keep two future versions
in jira - one for the current phase of development and one for bugs
that we want to fix but "won't be looking at anytime soon". This
second version is helpful for quickly deciding which general bucket
things go in to and also helps keep the list of current version bugs
smaller for me to browse through when deciding what to fix.
No one has freaked out and complained when I moved their bugs marked
for fix in current release to next release when they didn't make it
in, but maybe they'll hold Howard's feet to the fire more because of
his role in the project.
Either way - he who does the work decides how the work gets done - so
I support whatever he wants to do from that pov. ;)
On Jan 3, 2008 9:38 AM, Kevin Menard <km...@servprise.com> wrote:
> Clearly your the project lead, so up to you. In my experience, I've found
> it helpful. I typically have two or three versions open and scope out the
> work. If you want to focus on Ajax for 5.0.8, you can group all those
> issues there and 5.0.9 can be validation clean-ups or what have you. IMHO,
> it's nicer than just having a huge bucket of open issues that you cherry
> pick from. It also makes it nicer for your consumers to see what the plan
> is (it might help with all the "when is 5.0 final coming out?").
>
> --
> Kevin
>
>
> On 1/2/08 3:56 PM, in article
> ecd0e3310801021256t5c172a1fje8b75706614bce6d@mail.gmail.com, "Howard Lewis
>
> Ship" <hl...@gmail.com> wrote:
>
> > The roadmap is a good idea, but I have a problem with JIRA's release
> > note generator, since it generates a line for every bug with the
> > release number, whether its been fixed, resolved, marked duplicate, or
> > is still open.
> >
> > Roadmap is nice, but it really is about "geez, time for a release,
> > what can we fit in?" :-)
> >
> > On Jan 2, 2008 12:10 PM, Jesse Kuhnert <jk...@gmail.com> wrote:
> >> That's what I thought it was supposed to be used for..
> >>
> >>
> >> On Jan 2, 2008 3:08 PM, Kevin Menard <km...@servprise.com> wrote:
> >>> Is there any particular reason for that? It seems to me that if you defined
> >>> a fix version you could start using JIRA's roadmap feature. If the item
> >>> isn't resolved by the time you want to cut the release, JIRA has an easy
> >>> means of migrating all remaining issues to another fix version.
> >>>
> >>> --
> >>> Kevin
> >>>
> >>>
> >>> On 1/2/08 2:55 PM, in article 17207629.1199303734246.JavaMail.jira@brutus,
> >>> "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> wrote:
> >>>
> >>>>
> >>>> [
> >>>> https://issues.apache.org/jira/browse/TAPESTRY-1643?page=com.atlassian.jira
> >>>> .pl
> >>>> ugin.system.issuetabpanels:all-tabpanel ]
> >>>>
> >>>> Howard M. Lewis Ship updated TAPESTRY-1643:
> >>>> -------------------------------------------
> >>>>
> >>>> Fix Version/s: (was: 5.0.8)
> >>>>
> >>>> We don't define a fix version until a fix is committed.
> >>>>
> >>>>> @Mixin should accept parameters
> >>>>> -------------------------------
> >>>>>
> >>>>> Key: TAPESTRY-1643
> >>>>> URL: https://issues.apache.org/jira/browse/TAPESTRY-1643
> >>>>> Project: Tapestry
> >>>>> Issue Type: Bug
> >>>>> Components: tapestry-core
> >>>>> Affects Versions: 5.0.5
> >>>>> Reporter: Dan Adams
> >>>>>
> >>>>> With @Mixin there is no way to use a mixin that requires parameters within
> >>>>> a
> >>>>> component. For instance if you have a Confirm mixin that has a required
> >>>>> parameter you can't use it like this:
> >>>>> @Mixin
> >>>>> private Confirm confirm;
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Jesse Kuhnert
> >> Tapestry / OGNL / Dojo team member/developer
> >>
> >> Open source based consulting work centered around
> >> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry / OGNL / Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Fix versions
Posted by Kevin Menard <km...@servprise.com>.
Clearly your the project lead, so up to you. In my experience, I've found
it helpful. I typically have two or three versions open and scope out the
work. If you want to focus on Ajax for 5.0.8, you can group all those
issues there and 5.0.9 can be validation clean-ups or what have you. IMHO,
it's nicer than just having a huge bucket of open issues that you cherry
pick from. It also makes it nicer for your consumers to see what the plan
is (it might help with all the "when is 5.0 final coming out?").
--
Kevin
On 1/2/08 3:56 PM, in article
ecd0e3310801021256t5c172a1fje8b75706614bce6d@mail.gmail.com, "Howard Lewis
Ship" <hl...@gmail.com> wrote:
> The roadmap is a good idea, but I have a problem with JIRA's release
> note generator, since it generates a line for every bug with the
> release number, whether its been fixed, resolved, marked duplicate, or
> is still open.
>
> Roadmap is nice, but it really is about "geez, time for a release,
> what can we fit in?" :-)
>
> On Jan 2, 2008 12:10 PM, Jesse Kuhnert <jk...@gmail.com> wrote:
>> That's what I thought it was supposed to be used for..
>>
>>
>> On Jan 2, 2008 3:08 PM, Kevin Menard <km...@servprise.com> wrote:
>>> Is there any particular reason for that? It seems to me that if you defined
>>> a fix version you could start using JIRA's roadmap feature. If the item
>>> isn't resolved by the time you want to cut the release, JIRA has an easy
>>> means of migrating all remaining issues to another fix version.
>>>
>>> --
>>> Kevin
>>>
>>>
>>> On 1/2/08 2:55 PM, in article 17207629.1199303734246.JavaMail.jira@brutus,
>>> "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> wrote:
>>>
>>>>
>>>> [
>>>> https://issues.apache.org/jira/browse/TAPESTRY-1643?page=com.atlassian.jira
>>>> .pl
>>>> ugin.system.issuetabpanels:all-tabpanel ]
>>>>
>>>> Howard M. Lewis Ship updated TAPESTRY-1643:
>>>> -------------------------------------------
>>>>
>>>> Fix Version/s: (was: 5.0.8)
>>>>
>>>> We don't define a fix version until a fix is committed.
>>>>
>>>>> @Mixin should accept parameters
>>>>> -------------------------------
>>>>>
>>>>> Key: TAPESTRY-1643
>>>>> URL: https://issues.apache.org/jira/browse/TAPESTRY-1643
>>>>> Project: Tapestry
>>>>> Issue Type: Bug
>>>>> Components: tapestry-core
>>>>> Affects Versions: 5.0.5
>>>>> Reporter: Dan Adams
>>>>>
>>>>> With @Mixin there is no way to use a mixin that requires parameters within
>>>>> a
>>>>> component. For instance if you have a Confirm mixin that has a required
>>>>> parameter you can't use it like this:
>>>>> @Mixin
>>>>> private Confirm confirm;
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Jesse Kuhnert
>> Tapestry / OGNL / Dojo team member/developer
>>
>> Open source based consulting work centered around
>> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Fix versions
Posted by Howard Lewis Ship <hl...@gmail.com>.
The roadmap is a good idea, but I have a problem with JIRA's release
note generator, since it generates a line for every bug with the
release number, whether its been fixed, resolved, marked duplicate, or
is still open.
Roadmap is nice, but it really is about "geez, time for a release,
what can we fit in?" :-)
On Jan 2, 2008 12:10 PM, Jesse Kuhnert <jk...@gmail.com> wrote:
> That's what I thought it was supposed to be used for..
>
>
> On Jan 2, 2008 3:08 PM, Kevin Menard <km...@servprise.com> wrote:
> > Is there any particular reason for that? It seems to me that if you defined
> > a fix version you could start using JIRA's roadmap feature. If the item
> > isn't resolved by the time you want to cut the release, JIRA has an easy
> > means of migrating all remaining issues to another fix version.
> >
> > --
> > Kevin
> >
> >
> > On 1/2/08 2:55 PM, in article 17207629.1199303734246.JavaMail.jira@brutus,
> > "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> wrote:
> >
> > >
> > > [
> > > https://issues.apache.org/jira/browse/TAPESTRY-1643?page=com.atlassian.jira.pl
> > > ugin.system.issuetabpanels:all-tabpanel ]
> > >
> > > Howard M. Lewis Ship updated TAPESTRY-1643:
> > > -------------------------------------------
> > >
> > > Fix Version/s: (was: 5.0.8)
> > >
> > > We don't define a fix version until a fix is committed.
> > >
> > >> @Mixin should accept parameters
> > >> -------------------------------
> > >>
> > >> Key: TAPESTRY-1643
> > >> URL: https://issues.apache.org/jira/browse/TAPESTRY-1643
> > >> Project: Tapestry
> > >> Issue Type: Bug
> > >> Components: tapestry-core
> > >> Affects Versions: 5.0.5
> > >> Reporter: Dan Adams
> > >>
> > >> With @Mixin there is no way to use a mixin that requires parameters within a
> > >> component. For instance if you have a Confirm mixin that has a required
> > >> parameter you can't use it like this:
> > >> @Mixin
> > >> private Confirm confirm;
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Jesse Kuhnert
> Tapestry / OGNL / Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Fix versions
Posted by Jesse Kuhnert <jk...@gmail.com>.
That's what I thought it was supposed to be used for..
On Jan 2, 2008 3:08 PM, Kevin Menard <km...@servprise.com> wrote:
> Is there any particular reason for that? It seems to me that if you defined
> a fix version you could start using JIRA's roadmap feature. If the item
> isn't resolved by the time you want to cut the release, JIRA has an easy
> means of migrating all remaining issues to another fix version.
>
> --
> Kevin
>
>
> On 1/2/08 2:55 PM, in article 17207629.1199303734246.JavaMail.jira@brutus,
> "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> wrote:
>
> >
> > [
> > https://issues.apache.org/jira/browse/TAPESTRY-1643?page=com.atlassian.jira.pl
> > ugin.system.issuetabpanels:all-tabpanel ]
> >
> > Howard M. Lewis Ship updated TAPESTRY-1643:
> > -------------------------------------------
> >
> > Fix Version/s: (was: 5.0.8)
> >
> > We don't define a fix version until a fix is committed.
> >
> >> @Mixin should accept parameters
> >> -------------------------------
> >>
> >> Key: TAPESTRY-1643
> >> URL: https://issues.apache.org/jira/browse/TAPESTRY-1643
> >> Project: Tapestry
> >> Issue Type: Bug
> >> Components: tapestry-core
> >> Affects Versions: 5.0.5
> >> Reporter: Dan Adams
> >>
> >> With @Mixin there is no way to use a mixin that requires parameters within a
> >> component. For instance if you have a Confirm mixin that has a required
> >> parameter you can't use it like this:
> >> @Mixin
> >> private Confirm confirm;
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry / OGNL / Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org