My take on this is that it's best to keep separate branches.
Following a
consistent naming scheme for the branches would be a necessity for any
sort of automated management, and would be a good idea in general.
...
My thoughts exactly. Tags are fine for small things, but either
branches or version-checking methods are the way to go for more
advanced support.
This is the pattern we've been moving toward internally -- do three
votes count as consensus? :)
I can (maybe) find some time soon to start going through the core
extensions and making sure everything's got at least a 0.7 or 0.8
branch, if not both. For some of our own not-yet-released extensions,
I've actually done away with the master branch and set the default
HEAD ref to 0.8, just so there's no confusion as to what the current
line of development is. Yea? Nay?
The biggest problem as I see it is that many extensions are graciously
released to the world for use, but that doesn't mean the author will
be everyone's tech support. So they are released at version X and by
the time version Y comes around many people are using it but the
author is off doing something else (and not busy updating his/her
extension).
I think it would be nice if Radiant had some way to check for features
that were added in different versions.
I've been tinkering with the extension_config features and I may toss
in some way of specifying that an extension is compatible with a
particular version(s) of Radiant -- something that would work both
when Radiant is gemmed and vendored. Not a perfect solution, since as
you point out this isn't necessarily future-proof, but it would at
least alert a developer up-front when they try to install something
that isn't backwards compatible.
j
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
