tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Kuhnert" <jkuhn...@gmail.com>
Subject Re: Fix versions
Date Thu, 03 Jan 2008 15:14:27 GMT
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 <kmenard@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" <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
>
>



-- 
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


Mime
View raw message