tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Menard <kmen...@servprise.com>
Subject Re: Fix versions
Date Thu, 03 Jan 2008 14:38:30 GMT
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" <hlship@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 <jkuhnert@gmail.com> wrote:
>> That's what I thought it was supposed to be used for..
>> 
>> 
>> On Jan 2, 2008 3:08 PM, Kevin Menard <kmenard@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)" <dev@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


Mime
View raw message