mikelietz wrote: > Any thoughts? I have a couple.
Yes, I think that development should happen in branches, not in trunk. In this way we can prepare releases for different versions of Habari, which will be more important when we start releasing major version numbers where the API doesn't change. Note that plugins should probably take on the same API-to-version number characteristics of the core software. That is, API changes incite major version number revisions, and feature additions that don't affect API are minor versions. All bets are off on API stasis up until a 1.0 release. You know the drill. I agree we should use the convention you suggested, but to perhaps clarify: branches/0.6-0.x : This branch works with Habari 0.6, and houses versions 0.1 to 0.100 (or whatever) of the plugin while it's in development. tags/0.6-0.1 : This tag is for the 0.1 version of this plugin that works with Habari 0.6. tags/0.7-0.2 : This tag is for the 0.2 version of this plugin that works with Habari 0.7. If version 0.1 of a plugin continues to work with the next version of Habari, then the tag can be copied to the next core version number, ala 0.7-0.2 to 0.8-0.2. The development branch for the 0.2 version of the plugin would be copied from 0.7-0.x to 0.8-0.x, and development in 0.7-0.x would cease. These things become more important when we reach full Habari version numbers. Our 1.x release of Habari should have plugins that use 1.x in their branch names: branches/1.x-0.x : This is the development branch for a plugin targeting Habari 1.0 through 1.100 (or any minor version). branches/1.x-1.x : This is the development branch for a plugin targeting Habari's 1.x series, and it is internally API-stable. tags/1.x-1.1 : This is the released tag for a plugin on Habari's 1.x series, and has bug fixes or API-unrelated feature additions from the plugins 1.x branch. Note that the tags have full version numbers for the plugin version, just like Habari has full version numbers for its released tags. Using this release strategy, we can easily tell (and use automation to discover) what the most recent version of a plugin is for each version of Habari (if available), and whether there is an official release and/or in-development version of the plugin in source control. Concerning the issue of trunk: Yes, I think we should abandon trunk development for plugins. If development happens in the branch, there's no guessing at what version it is and what version of Habari's API it targets. That said, I think we should avoid an automated process that moves everything from trunk to a branch. The reason I say this is because not every plugin is compatible with the current Habari version, and there's no way to tell if a plugin is being maintained or for what version of Habari it might be targeted. Part of the purpose of this is to better keep a handle on what versions of plugins can work with what versions of Habari, so a wholesale move seems unwise. Manually verifying plugin compatibility and moving seems like a better course to me. 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 -~----------~----~----~----~------~----~------~--~---
