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]
