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 [EMAIL PROTECTED], "Howard Lewis Ship" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >> That's what I thought it was supposed to be used for.. >> >> >> On Jan 2, 2008 3:08 PM, Kevin Menard <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED], >>> "Howard M. Lewis Ship (JIRA)" <[email protected]> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
