[Trac] Dates on versions and milestones

Ronny Hanssen ronnyh at tihlde.org
Fri Apr 8 17:10:20 EDT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

These are my interpretations on the issues that you bring up:

Versions (tracking published releases):
I use the versions to track my *already released* versions of software.
Reason being that the version field is only an attribute to the ticket
when registered. Such as which version of the software were you running
when you encountered the bug. Or, which version is the background for
suggesting new features (sometimes the users may ask for a feature, and
I'll get into a debate with them because a later version has this
implemented, but they haven't seen it yet. This way it's more probable
that I can inform my users of this change in a later version, instead of
believing that they don't understand the feature or if they think the
feature is badly implemented.

Milestones (planning upcoming releases):
This is for planning. A milestone can be anything you like it to be. A
major or minor upgrade - anything. Some use it for much smaller
timespans, like every 14 days or so they plan on having a set of
bugs/features closed. When the period is over they either move
unfinished tickets to the next period, or they change the date for the
milestone. Eventually they have external or "proper" releases too, and I
guess that it makes sense to use the milestones for that too. Milestones
are great for planning on when to do the different
bugfixes/enhancements/features, but as you progress you can also see how
complete each milestone is. The only thing I am missing here is the
duration though... I'd love to see a duration built into the standard
trac, instead I know have to add it via custom changes. Tiresome, and
not a perfect solution. Still misses calculation of totals and alike.


Regards,
Ronny

Robert Morris wrote:
> Hello Trac Mailing List,
> 
>  
> 
> Seem to be having some trouble conceptually about trac and I have some
> questions.
> 
>  
> 
> The ?version time <name> <time>? allows one to assign a date to a
> version.  I see no effect
> 
> when assigning a date to a version on any of the (default provided) web
> pages for Trac.  What
> 
> is the effect of putting a date on a version ?
> 
>  
> 
> Is that the date when the version should be complete ?  Can?t kick this
> up in docs
> 
> anywhere or in the mailing lists.
> 
>  
> 
> What is the effect of putting a date on a milestone ?  Is do see
> _/some/_ effect in this
> 
> case (in milestone view).  Is that the date the milestone is completed
> and you enter it
> 
> when it gets reached ?
> 
>  
> 
> Now conceptually I may have things backwards.  I have milestones names
> similiar
> 
> to ?Executive 1.7D Release?.  I also have a version named ?1.7D?.  Does
> this run counter
> 
> to the intent ?  Should milestones be ?major functionality? and versions
> and the numbers
> 
> assigned to releases of our software ?
> 
>  
> 
> When one assigns a version to a ticket ? is it the version one has to
> change or is it
> 
> the version that the ?change goes into? ?
> 
>  
> 
> Not sure, I?m thinking these conceptual issue are perhaps deliberately
> vague in some
> 
> cases to allow the users to use it as they will.  If so, perhaps let me
> know that so I could
> 
> stop looking if you would please.
> 
>  
> 
> Thanks,
> 
> Rob
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Trac mailing list
> Trac at lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac

- --
- ------------------------------------------------------------------------
/*Ronny Hanssen*/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCVvM7MRRzQX3ma+kRAvCGAKCVFgABWz4EvqgH0jeUVQHxU9NTpQCfaEZe
T7R1rZKKdZePUfRZ/YxOjR4=
=2olN
-----END PGP SIGNATURE-----


More information about the Trac mailing list