On Jun 25, 3:08 am, "Ali B." <[email protected]> wrote: > The idea is to eventually avoid that "nightmare". > > Plugins zip's would be built from tags that are created on the different > plugins branches. For stable versions of plugins, ie branched and tagged for > the latest stable habari release, users will be able to download that > specific zip. People running habari head HEAD, will need to check out the > plugins from their habari upcoming versions branches using svn (They are > running habari dev, you'd assume that there would not be an issue running a > dev versions of the plugins).
No, tags should be created from trunk, not a branch as I understand subversion and version control. Branches can be for development, but should be eventually merged back into trunk, same as we do with core. If and when we were to get to 2.0, then yes, there'd be a 1.x branch I'd assume. > > This would mainly allow easy developement and release for more than one > plugin version for the same habari version. I don't see how this can be done > all within trunk without having to revert changes, tag and then reapply. > Quite messy. I don't understand. "more than one plugin version for the same habari version"? why would there be different versions of the same plugin that work with a specific version of Habari? If they are that different, then the plugin should be forked and have it's own separate branches/tags/trunk hierarchy. > Another problem with the past setup is that we cannot keep packaging > plugin's trunk. Plugin's trunk is, normally, used for developement and not > stable releases. Agreed. Zips should be built from tags. > Because -extras is currently in this transition, You should obviously expect > some sort of mess. Evnetually, all plugins will have a branch for the > current version (and it's major point version), and (if required), a branch > for the alpha version currently in developement. Again, this is where we differ. I don't understand why trunk wouldn't be used for current development. Sure, one might create a branch for something extremely ambitious (again, same as we do with core, think Monolith), but it would be merged back to trunk once deemed ready, not tagged from there. > This will, as a result, deem trunks obsolete. Unless you want to merge back > from the latest branch back to it when you want to create a new branch. Yes. The way I see it is once .7 is gold, we merge that branch back into trunk, potentially tag a stable release, and go about our merry way. We won't be supporting .6, so why would we bother with trying to legacy support plugins for that version? As far as when we get to 1.0, the way I understand versioning, there shouldn't be any drastic changes to the codebase in 1.x as to need separate branches for each point release. > One last thing to add is that with or without the new svn "restructure", > plugins' trunks will break for people running 0.6 since most of them will be > up'ed to be used with the latest habari HEAD. > See, the way I understood it, the whole reason we did this .6/.7 branching was so that people running .6 could still download the plugins from -extras dist and work with their version (as the zips are still built from trunk). However, that hasn't been followed across the board. Code Escape and Database Optimizer were two that I ran across that were updated in trunk for .7, but weren't branched at all, nor did I see a .6 tag. So we aren't collectively even following the same process. I just don't understand why we would adopt a completely different method of development for plugins than core. I mean, I get that we branched for .7 changes, as nothing is completely set in stone for the pluggable method, and we haven't worked out a solution for offering downloads. We aren't abandoning trunk for core are we? By this system, we would be doing all of the development to core in a .7 branch, tag a release from there, and then start a .8 branch, wash-rinse-repeat… Anyway, I don't want to sound like I'm beating a dead horse, or come across as too argumentative. I've expressed my opinion, and will wait to (hopefully) hear what others have to say. ~miklb --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
