Uh... I love top postings... :) Erik Andersson kirjoitti: > You can use version to report in which version a bug was found. The > milestone is used to plan in which release the fix will be implemented.
And when milestone is completed there is no means to convert it with ease to version. Also Trac documentation doesn't indicate that milestone is version - it just indicates that milestone is "named point in the future that has possibly date set". Note that Trac project itself uses milestone as future version. > On Tue, Apr 22, 2008 at 10:19 AM, Doc <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > I'm confused mostly about the "versions". What is the meaning of > having a version? All I see on Trac's site (trac.edgewall.org > <http://trac.edgewall.org>) is > milestones. All reporting and project management seems to be around > milestones. What are versions for? Like state somewhere above there, versions work mainly with defects (bugs). You can mark that bug is related to some spesific version. > I read somewhere that milestones are supposed to be future feature > packs, and versions are supposed only to indicate which release (in > the past) each ticket did actually get into. But that seems > incomplete, as it would indicate that there would also be some > mechanism to mass-assign tickets to versions (e.g. assign a completed > milestone to a version/release). That seems intuitive, and that's the > way I'd like to work, with the following clarifications: > - Each milestone would be a batch of tickets needed to complete a > feature (i.e. milestones are features of the project, which seems to > be about the way they are being used already). And this is how I guess most of us are using milestones. Except that version is used tightly coupled with defect-type tickets. Tasks and enhancements (in default installation) are rarely assigned to version since version is usually used to mark "where I found this issue". That's why there is no mass operation for that. > - Each version would be a bunch of milestones/features that have been > included, or are expected to be included in that release (i.e. a > version is a release), depending on the release date (whether it's in > the past or future Trac doesn't really have this kind of feature. So you can't easily plan "release" that contains multiple milestones. That would be lovely feature specially if someone is running scrum-like process releases usually covers multiple milestones (sprints). Also you don't reassign tickets to spesific version afterwards this will create very interesting feature specially if you think defect-type tickets... > This way it is possible to track features and plan releases (i.e. by > adding/subtracting features, thus postponing or hastening a release). > How about that? In theory this could be done with custom field in ticket and maybe a plugin to handle reporting and automatic transition from planned release to published version. -- Jani Tiainen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
