2009/6/29 luke <[email protected]>: > Owen wrote: >> Apart from that one change - letting trunk stay and be active - I think >> we should stick with the plan as described, and I will explain not only >> how it will benefit you, but also how another large project with a huge >> contributor base does nearly the exact same thing to great effect.
To summarise, I think this is where we stand in regard to plugins: (and please point out here if I've missed anything or I'm wrong) * trunk is for active development, it's unstable, and people using it should use svn. Currently, trunk should work for 0.7. * On release of a version of Habari, a tag should be created. Use it as an external if you like. If the plugin hasn't changed since the last release and still works, you can just copy the previous tag. If there isn't an appropriate tag, you might consider creating one. Currently there should be a 0.6-(\d+).(\d+) tag for all plugins. * If there are fixes for a plugin targeted at a released version, a branch should be made from the appropriate tag, the fix made, and a new version tagged. There's no need to automatically create a branch when a release of Habari is made. * Tagged things should have a distribution created automatically (which doesn't happen yet, but when it does it should tie into the addons directory). * Other branches can exist for experimental features, and you can do whatever you like with them. To move forward from here: * Ensure there is an appropriate and working 0.6 tag. In most cases this will mean tagging the 0.6 branch after testing. In the few cases where no 0.6 tag or branch was made, it will mean branching an earlier revision for 0.6, testing (and removing the XML file if there was one) and tagging from there. * Make sure trunk works with 0.7. In most cases this will mean merging the 0.7 branch back to trunk. Where trunk has been removed, it needs to be restored. > Soooo. this all sounds pretty good. I have one last being-the-annoying- > guy thing. This needs to be written up as documentation somewhere so > that plugin developers follow it. Probably the wiki. Otherwise it's > just talking. Thoughts? Is there a better location? The right location for documentation is http://wiki.habariproject.org/en/Extras_Repository. -- Michael C. Harris, School of CS&IT, RMIT University http://twofishcreative.com/michael/blog IRC: michaeltwofish #habari --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
