TracRoadmap for 1.0 and beyond

[Christian Boos]

Hello,

FYI, I updated the good old http://trac.edgewall.org/wiki/RoadMap page
to explain a bit better the differences between the pre-1.0 model and
the new one, post-1.0. I think it shows nicely where we come from and
where we aim at, at least release-wise.

About the future steps themselves beyond 1.0, I still need to find a
proper way to convey some of the new ideas which I got recently, but
this will probably take the form of yet more wiki page ;-) I think I'll
expand the TracDev/ScratchPad pages, to bring different ideas and
thoughts about specific topics in one place, where they can serve as
guidelines. One such attempt was
http://trac.edgewall.org/wiki/TracDev/ScratchPad/ChangesetModule

But I can already talk about one of the main idea concerning the
architecture I had recently. I think that I now see a way past the
Genshi dilemma (namely, "it's a performance killer, but we need this
level of flexibility and content transform for the sake of
extensibility"). Instead of moving to yet another template engine, let's
acknowledge that server-side rendering is behind us and move to a model
where progressively more stuff is done in JavaScript on the client-side.
We'll keep the same level of flexibility and extensibility that we have
now with Genshi, yet produce very simple HTML, mainly a skeleton, the
JavaScript data (json as the new hdf ;-) ) and the scripts that are
relevant for that page. Two early steps in this direction could be seen
in #10714 and #10735.

I also take the opportunity of this mail to mention that I've moved the
TracMercurial plugin development to a proper hg repository (at last!).
See http://trac.edgewall.org/browser/mercurial-plugin

(now I need to go back finishing my 1.0 tickets ;-) )

-- Christian