Lately, I was working on the ticket #2945 (ticket with version control).
Like I commented on that ticket a while ago, we already had all the
needed information at hand, so adding this feature was merely adapting
what we already had in place for the Wiki module to the Ticket module.
Of course, the APIs and the datamodel are quite different and therefore
the implementation in the controllers differs a lot too.

But I'm sure you're familiar with this old motto of mine, "things
shouldn't need to be that way, as they're all Trac objects after all".
So while I've been ranting since a long time about the need to make
things a bit more homogeneous on the UI and data model levels (1), I've
recently made some progress about the possible solutions, most notably
by developing the DataModel proposal (2), the Journaling proposal (3)
and suggested a tab-based layout to solve some navigation issues (4).

So now I'd like to take this a step further and implement these ideas.
What makes it a bit difficult is that everything is inter-related, so I
was looking for some guideline. I think that following-up on the #2945
addition is inspiring in several ways:
 1. On the presentation level, I could try out the idea of having tabs
for viewing a resource (''View'' and ''History'' tab for any given
resource).
 2. On the presentation and API level, I could try to factor common
things between the wiki and ticket modules
 3. On the data model side, I'd like to start to implement the DataModel
proposal for the Milestone, so that things like #1673 (History for
milestone description text) can get implemented. That would provide the
basis for a generic implementation that could afterwards be ported to
the Wiki and Ticket modules.
 4. Likewise, implementing the Journaling changes on the level of the
Milestone would provide a new way to do the change listener interfaces
and notifications, that could later be retrofitted for the other modules
as well.
 5. While working on the above, I hope to be able to further refine the
way one could have a minimal generic API for all the Trac resources, so
that I can revive my xref branch and turn it into a plugin. I'll
hopefully soon follow-up on that by writing a ResourceDescriptor proposal.

So that may seem to be a lot of things, but like I said, I'll probably
start small by doing the changes for the milestone only,in a way that
shouldn't require an "upgrade".
I don't know exactly what would be the best approach regarding branches:
 - create small branches for each topic (e.g. tabs, history-refact,
datamodel, journaling, resource)
 - let things evolve together in an experimental sandbox (e.g.
milestone-refactoring), as the different topics are inter-related; then,
when the approach stabilize, prepare new branches for retrofitting the
new data model to each existing module, one branch per module.

My favored approach would be a 'tabs' branch for point 1. do 2. on trunk
directly, and work on 3,4,5 on a 'milestone-refact' branch.

-- Christian

(1) - http://trac.edgewall.org/wiki/TracObjectModelProposal
(2) - http://trac.edgewall.org/wiki/TracDev/Proposals/DataModel
(3) - http://trac.edgewall.org/wiki/TracDev/Proposals/Journaling
(4) - http://trac.edgewall.org/wiki/TracProject/UiGuidelines