Remy Blank wrote:
> Christian Boos wrote:
>
>> /plugins
>> /0.10
>> /WebAdmin
>> /0.11
>> /mercurial-plugin
>> /spam-filter
>> /0.12
>> /spam-filter
>> /multirepos
>> /mercurial-plugin
>>
>
> (snip)
>
>
>> 0.X/trac/*
>> 0.X/trac/<module>/*
>> 0.X/tracopt/<module>/*
>> ...
>> /plugins/0.X/<plugin>/tracext/*
>> 0.X/sample-plugins/<single-file-plugin>.py
>> ...
>> 3rd party plugins
>>
>
> I assume you chose the {version}/{name} scheme instead of
> {name}/{version} as on trac-hacks for symmetry with the rest of the Trac
> repository? That may make it a bit more difficult to find the latest
> version of a plugin, in the case where e.g. there's no 0.12 version for
> a plugin, and the 0.11 version can be used. But I think I like your
> scheme better, too.
>
The big advantage is that this makes it more natural to phase out
plugins that were integrated in the core. Otherwise we would carry a
/plugins/webadmin forever, and with the above scheme it gets hidden in
the /plugins/0.10 folder where nobody will look at ;-)
The disadvantage is as you said, but I guess people will quickly get to
look into the folder for the version they are using.
For plugins that are actually unchanged between different versions, we
could just have a copy and use merge tracking.
This is to be preferred to "linking", as: 1/ we don't support linking
(#2566), 2/ we should better change the plugin version anyway (e.g.
0.11.0.2 vs 0.12.0.2).
For "branches", we should put only the plugin(s) relevant to that
branch, the others can be taken from the version on which the branch is
based upon.
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" 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-dev?hl=en.
