I was in a poor mood last night as I attempted to implement the schema, and apologize for the resultant rudeness.
I would be willing to write some documentation, though keep in mind it will be my interpretation of a somewhat vague XSD. For compatibility, I do think it is worthwhile to do both. Habari core should provide specific features which plugins can test against (ex. blocks). However, I do think there is additional value in a <compatible> field. The <compatible> field simply means "this plugin has been tested to work with this version." When constructing the extras repository, that'll be a useful field to leverage. I imagine that users don't want to have to hunt through Habari versions and find whether a feature is provided. I think it's useful for them to be able to see "will this plugin work with my version?" Regarding trunk development, I actually think <compatible> should only name released versions. Remember, <compatible> is not strictly enforced: it'll just say "this plugin might not work with your version if Habari." For bleeding edge development, I don't think we need to provide the same seal of testing. Plugins would simply rely upon features to determine compatibility with HEAD. ~arthus On Jun 20, 2009, at 10:52 AM, Owen Winkler wrote: > > Arthus Erea wrote: >> Please write some documentation. >> >> Please respond to criticism and admit you're not infallible. > > The Pluggable XML format does need some more written-language > documentation, even though the XSD is mostly complete. (Some guidance > from those who know on how to correct the XSD to work with non-local > validators would be helpful.) > > Until that documentation is written (which you are welcome to begin, > instead of waiting for someone else), you can find these resources > here: > > Pluggable XSD: http://schemas.habariproject.org/Pluggable-1.2.xsd > Sample XML: http://schemas.habariproject.org/pluggable-sample.xml > > If while writing the documentation, you have specific questions, > posting > them here should yield specific direct answers and input from others. > > Regarding another query posed about tying plugins explicitly to Habari > versions -- > I'm unsure that this is the best approach, in the same way that I know > that a theme's requiring a specific plugin by name is the wrong > approach. Primarily my opinion on this is based on the concept that > it's not a version of Habari that a plugin targets, but a feature that > Habari provides. > > So the question is, should Habari itself provide "features", as > included > in the pluggable xml, that plugins can then require or recommend as > needed? > > Bear in mind that major version releases of Habari should be API- > stable. > So it would be useful to include a single feature of "Habari 1.0" > when > that time comes. But for the 0.x branch, features change so often, > especially in the trunk, that simply indicating "0.7" as a requirement > may not be enough. Especially for the useful features that we > continue > to modify and add in 0.7, an 0.7 Habari checked out at the beginning > of > the branch's life would not have any of the features implied by the > requisite of "0.7". > > 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 -~----------~----~----~----~------~----~------~--~---
