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 <[EMAIL PROTECTED]> 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 > [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] > > -- 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]
