milestone URL persistence

[john.williams@…]

I've been struggling with Milestone URL persistence. It a maintenance nightmare changing milestone names. Our implementation of Trac oversees a large number of disparate university groups each with multiple milestones. Each group has their own wiki pages linking to their milestones as well as milestones of other related groups.

I see ticket #364 mentioned this (jamesm about 6 years ago)

I realize its ugly, but I think that the ability to link to the milestone outweighs the benefits of a pretty-url. I would say go with a fixed integer (like tickets do) and let the user assign a name/descrption to the fixed integer. I think that the linking throughout Trac/outside Trac is more important.

I agree with this statement, permanent ID's, just like tickets, elegantly solve this issue. Further, a milestone with a fixed ID having a title and description field would be highly useful. Macros (such as MilestoneDate) could pull the title into a wiki for display letting the milestone names change independently of milestone links without losing any descriptive benefits.

I checked newer versions of trac hoping this was implemented, but I see no evidence

• ​http://trac.edgewall.org/demo-0.12/milestone/Feed%20the%20dogs

Link to a milestone I created but then changed the name

• ​http://trac.edgewall.org/demo-0.12/milestone/My%20name%20WILL%20change
• ​http://trac.edgewall.org/demo-0.12/milestone/My%20name%20changed

[Christian Boos]

Surrogate keys for Trac resources could well be implemented one day (see e.g. GenericTrac).

We currently do that for the repository resources, but in that case those ids are completely hidden from the user, and I'm not sure it would be a good idea to expose them, even when talking about milestones instead of repositories. I don't think that many people will be enthusiastic about having to write e.g. milestone:12 which could by chance point to the milestone named "0.11" for example ;-) Using something like milestone-id:12 would only be marginally better.

Alternatives which were already suggested are redirects after renames. That could work, but what if you really want to re-create a different milestone with the original name? The redirect will stop working.

The other possibility would be to rewrite all the incoming links, something we're anyway considering to support for WikiRenames in a future release. But that wouldn't work with external URLs you're concerned with.

So all things considered, if we move to surrogate ids, then it wouldn't cost much to offer a permalink somewhere on the Milestone page, maybe as an "Alternate Download Link - Permalink, pointing to e.g. /uids/milestone/<id>, which would be primarily useful for referencing in external systems.

But for TracLinks, I think we should keep using the intuitive milestone:<name> and the regular and discoverable URLs /milestone/<name>. An improved support for milestone renaming could be done by rewriting the incoming links in all other resources (but that could quickly prove too costly) or the use of a redirect table (further discussion about this in #3718).

[john.williams@…]

Replying to cboos:

You raise several good points. For me, as long as one can link to a milestone and not worry about a name change later, I'm happy. A name shouldn't be the thing. It is odd to me that having nice URL names for milestones sounds like a requirement, yet tickets never work that way that I'm aware of. I would expect the features of Trac to work in an orthogonal manner.

For wiki pages it seems that a macro to resolve the ID to the milestone's name field would be rather easy to do.

I don't think that many people will be enthusiastic about having to write e.g. milestone:12 which could by chance point to the milestone named "0.11" for example ;-)

I'd love this, if I can use this short-cut to specify a specific milestone, then that's wonderful. Again a milestone with discrete name and description fields would really help here.

To me, once a milestone is created (and in my case "assigned" to a project, see below) then it makes sense for those in the project to refer to the milestone in a concrete way.

Alternatives which were already suggested are redirects after renames. That could work, but what if you really want to re-create a different milestone with the original name? The redirect will stop working.

This is reasonable, but again a fixed ID would prevent this too.

The other possibility would be to rewrite all the incoming links

Sounds like a lot of work to implement and doesn't solve the general issue.

So all things considered, if we move to surrogate ids, then it wouldn't cost much to offer a permalink somewhere on the Milestone page, maybe as an "Alternate Download Link - Permalink,

This sounds reasonable. Ticket #3718 sounds reasonable to me too. However, both seem to create more work to implement to solve only part of an issue.

For an example: we have a large number of projects (which are components for us) and 100's of milestones. The milestone names are a bit verbose as they are outlining a contractual item that we are assigning to a particular project/contractor (e.g. "spiral 2 integration testing with X & Y") I auto generate these milestones from SOWs (statement of work) as well as auto-generate project's wiki when a new project is created. Milestones may be added later, etc etc.

It is up to the project whether they leverage our Trac instance for PM and ticketing for managing there project's progress to meet the outlined milestone. However, the milestone "contains" numerous tickets that we create outlining tasks for them to complete as the milestone (hence contract) requires. Some projects add extra tickets to track their work, some just email us when they finish a task and one of us closes the appropriate ticket. Either way, Projects link to milestones from internal and external sources ad these names do change. Managing Milestone links has become such an issue that we are contemplating issue tickets for milestone changes to ensure they get updated by those in a project and by one of us on our Trac site!

[Christian Boos]

Replying to john.williams@…:

A name shouldn't be the thing. It is odd to me that having nice URL names for milestones sounds like a requirement, yet tickets never work that way that I'm aware of.

But I think that for most projects using Trac (at least most of those I came across), the name is the thing, the milestone has the name of the next release, some intermediate milestone, or some name with a relatively fixed and stable meaning (e.g. "Blue Sky Ideas"). Trac users are certainly used to and happy with this simple association…

Transpose this to a Wiki page, there also the WikiPageName is the page. When linking from one wiki page to the next, you wouldn't want to use the internal id of wiki page, even if that would be more "robust" and better identify the resource you're talking about; even if what would be displayed would be the page name, you just wouldn't write it like that.

Tickets are at the other end of the spectrum, they have a clearly defined identity, but it's not easy to associate a good name to them (the summary often changes).

Now milestones lie somewhere in between and there are situations (like yours) where milestones can be seen closer to tickets than to wiki pages. See also the discussion in SubTickets.

I would expect the features of Trac to work in an orthogonal manner.

Me too, and I'm still trying to make that happen ;-)

For an example: […] The milestone names are a bit verbose as they are outlining a contractual item that we are assigning to a particular project/contractor (e.g. "spiral 2 integration testing with X & Y")

But isn't that a bit "overloading" the milestone name? Perhaps if you had the possibility to associate more information to milestones (i.e. milestone custom fields), the name would be less likely to change …

[lkraav <leho@…>]

following, this presses my buttons in a number of trac realms, i.e. ​th:FullBlogPlugin, etc.

[john.williams@…]

Replying to cboos:

Now milestones lie somewhere in between

I agree - and it gets even more grey with the way we use Trac.

For an example: […] The milestone names are a bit verbose as they are outlining a contractual item that we are assigning to a particular project/contractor (e.g. "spiral 2 integration testing with X & Y")

But isn't that a bit "overloading" the milestone name? Perhaps if you had the possibility to associate more information to milestones (i.e. milestone custom fields), the name would be less likely to change ..

Also Agree and yes this would be useful in several ways.

More than anything I wanted to raise the point that static linking (or a close approximation) would save people a significant amount of time for maintenance. It seemed that this was a decision point along time ago so I wanted to bring it up.

For background:

I've used administered Trac in several other companies with more of a software focus and have always been happy with it. This instance of trac is geared more for program management & system's integration with software being a lesser focus. The usage of a milestone is traditional in the sense it holds a grouping of tickets that are to be finished by a date. On the other hand, they are a bit more fine-grained (or, overloaded) than usual and usually refer to a single component.

I thought of using tickets with due dates and bumping the granularity of the milestone up one level but this doesn't solve the issue, induces a few others significantly impacts workflow. I'm inferring that the term "milestone" has some weighted significance to contracting personnel, as opposed to a "Release" which is what the roadmap view displays anyhow.

[Christian Boos]

Milestone 2.0 deleted

[Christian Boos]

RedMine has an alternate syntax for linking to resources via their ids instead of their name, hence we could have not only things like milestone:1.0 but also milestone#123 to link to the milestone with the internal id 123 (see ​Redmine links).