Michael C. Harris wrote: > > I think we're settled on the current svn structure (I don't think Sean was > suggesting we change that). The issue is, if Mr Punter downloads a version of > a > plugin from trunk, and it's version 0.7-0.2, more development happens, then > version 0.7-0.2 is tagged, we have no way of knowing what version they're > using from inside the plugin.
It seems reasonably trivial to add "-dev" to the version of a plugin that is produced for /dist/plugins from a 0.x branch, assuming the plugin info xml is well-formed. For those grabbing the plugin from svn, they can easily tell what they've got by using `svn info` on the plugin directory, or we could throw them a bone and add something like what is in Habari's core for detecting revision information to the Plugins class. Of particular importance to me in this thread is a sentiment I read in the IRC log, reproduced for you here: [06:13:07] <scoates> think of a scenario like this: you have a plugin called bottle. Another plugin called beer. Beer depends on bottle 0.4 to work. There'd be a way to programmatically check that you have bottle at _least_ version 0.4 if it had a 0.4 number. If bottle was called 0.x, then there'd be no way to check that dependency. Version number checking like this should NEVER EVER be done. I've been trying to beat this into everyone for a very long time and I'm reasonably sure that it's legacy behavior that causes the dissonance. I'll explain. Whether a plugin is compatible with the environment it runs in is not a facet of the version of the plugin. A plugin that uses a single, simple hook that operates the same way through 4 core versions of Habari should not need to update its compatibility requirements to keep up with those Habari releases. Likewise, a theme that requires a tag cloud should not look for a plugin named "RNTagCloud" nor should it look for a specific version of a specifically-named plugin. Instead, we keep a catalog of feature tags to use in the "requires", "conflicts", "recommends", and "provides" sections of the plugin info xml. The core system reports on compatibility between previously installed items and new items. The end result includes many positive things: * Plugins that interoperate with features will continue to work as long as those features are present, without checking version number compatibility. * It will be possible in advance of an upgrade to see not only which plugins will break, but why. * It will be possible to provide a list of plugins or themes that will provide the features that some other plugin or theme requires. None of that works really well with simple version number checking, and I believe it's one of the major complaints people have about OBT that I would personally love to address. Even doing it this way, API compatibility makes sense to do (since that's how we're delineating core major versions) by using a "core-1.x" (literally "x") feature tag. To wrap back around to version numbers: Version numbers are a useful primary indicator for what version of a plugin is the latest and should be compatible with the version of Habari that is installed, but they should not be the ultimate indicator of compatibility. Sorting out whether a plugin is an in-development version of a specifically-versioned plugin seems the only real concern, since it would otherwise be difficult to tell. Owen -- 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/habari-dev
