thoughts about milestone and version

[Brettschneider Falk]

Hi,

while hacking on further extensions to http://trac-hacks.org/wiki/SimpleMultiProjectPlugin, and as we came across the relations between milestone<->project and version<->project, I wondered what actually the difference is between milestone and version in the architecture model. It looks to me, both are just 2 types of events on a timeline, or even there is a 1:1 relationship between milestone and version. Though there is ISO 9001 (SW quality management standards) defining 5 standard milestones, and some here say those should be timeline events 'milestones', and all other ones are just 'version' events.
Thinking about that now my opinion is a Trac milestone actually is a simple 'date' (or event or deadline). Furthermore 'version' and 'milestone' are just special subsets inheriting 'date', while 'milestone' probably is a subset of 'version'. Using Trac in other environments than software development may define other subsets of 'date'.

After all I want to ask why you don't merge the database tables 'milestone' and 'version' to a new table 'date' where version number is just another property.

This would also solve the problem that on ticket creation people often ask what they should type in ticket fields 'version' and 'milestone', and what the difference is. Since every Trac milestone has a version here, I explain it as version="seen in version" and milestone="scheduled to be closed with version". But that doesn't explain why both ticket fields offer different sets of choices.
For our needs I'm thinking about reflecting the 'version' table also on the roadmap page, either handling them as own dates or as properties of dates.
Maybe there is a good wiki page explaining the backgrounds of why the data model is as it is today.

CU, F@lk

----
Falk Brettschneider
R&D Software
Baumer Optronic GmbH
www.baumer.com



Gesch?ftsf?hrer: Marcel Seeber * Dr. Oliver Vietze
Sitz der Gesellschaft: Radeberg
Amtsgericht Dresden: HRB 15379
Ust. ID: DE 189714583

[RjOllos]

On Tuesday, June 5, 2012 1:14:31 AM UTC-7, Brettschneider Falk wrote:

After all I want to ask why you don't merge the database tables 'milestone' and 'version' to a new table 'date' where version number is just another property.

The way my team uses Trac, milestones and versions don't map 1:1.  We may generate multiple versions in the course of a milestone.

Have you looked at the ExtendedVersionPlugin?

http://trac-hacks.org/wiki/ExtendedVersionPlugin

[Brettschneider Falk]

Hi,

RjOllos wrote:
> The way my team uses Trac, milestones and versions don't map 1:1.
> We may generate multiple versions in the course of a milestone.
>
> Have you looked at the ExtendedVersionPlugin?
>
> http://trac-hacks.org/wiki/ExtendedVersionPlugin

No, I didn't know it, thanks for the hint.

Looking at its wiki page, it looks as if it sets a 1:n relationship between version and milestone; as if several milestone dates can happen until a version date is reached so to speak. Here we have the case that we have more versions than milestones, each milestone is archived in an internal software version, sometimes there are more than one (=release candidates) versions until a milestone, and we also have several bugfix release versions after the last milestone. And for every version we need to work on some tickets that needs to be shown as progress bar. You see in the end all events are dates where some of them are milestones, and all of them are versions here though I can imagine also dates without a version, and a milestone may be without a new software version.
Is ExtendedVersionPlugin suitable for such world?

[Franz]

Hi Falk,

there is a Component in Trac under sample-plugins, called
"milestone_to_version.py". The description is as following:

"Automatically create a version when a milestone is completed. Sample
plugin demonstrating the IMilestoneChangeListener interface. Creates a
version from a just-completed milestone based on whether the
milestone's name matches a specified pattern."

We use this Component for quite a time now. I packaged it for
convinience into TicketNavPlugin (see [1]), but you could also just
copy it into $PROJECT/plugins directory and enable it.

Hope this helps,
Franz


[1] http://trac-hacks.org/wiki/TicketNavPlugin

[Franz]

On Jun 5, 10:14 am, Brettschneider Falk <fbrettschnei...@baumer.com>
wrote:

> This would also solve the problem that on ticket creation people often ask what they should type in ticket fields 'version' and 'milestone', and what the difference is. Since every Trac milestone has a version here, I explain it as version="seen in version" and milestone="scheduled to be closed with version". But that doesn't explain why both ticket fields offer different sets of choices.
> For our needs I'm thinking about reflecting the 'version' table also on the roadmap page, either handling them as own dates or as properties of dates.
> Maybe there is a good wiki page explaining the backgrounds of why the data model is as it is today.

Read your post a bit closer and found out that we had the same
problem. We solved it by using the Component MilestoneToVersion (see
[1]). IMHO version is different from milestone: version indicates the
version number where the bug occured and milestone is the target
version (when the target milestone has been finished it will be a
version).

HTH,
Franz


[1] http://trac.edgewall.org/browser/trunk/sample-plugins/milestone_to_version.py