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
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.

Radiant mailing list

Reply via email to