On Thu, Jun 25, 2009 at 11:09 AM, Michael Bishop <[email protected]>wrote:
> > 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. > That's often true. Although not in this case. See my answer for the multiple plugin version per habari release below. > > > 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. Say you have a plugin you are currently developing it for Habari 0.6. You've come to a point where you want to release it, but the feature would still work on 0.6 so you tag it as 0.6-0.1 (0.1 is the plugin version). Then you add cool feature or fix a nasty bug to that plugin and want to release that feature. You tag it 0.6-0.2. That's multiple plugin version for one Habari version. > > > 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. Contiuning from my answer on the previous quesion: What if, within the intial release of the plugin (plugin version 0.1), you wanted to have a version that is compatible with Habari 0.7? You create a branch from the trunk for Habari 0.7 support and make the plugin compatible with 0.7. You tag it 0.7-0.1. When you want to add the cool feature or fix the nasty bug on the 0.7 "edition" of the plugin, you commit your change and tag that branch 0.7. > > > > 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. An important difference to note between the -core and -extras is that with -extras the code would/may need to conform with more than one -core versions at a given time. While -core, you don't have to to conform with anything. > > > 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. > It's true. Few plugins have had their trunk updated. Making it a little harder for other contributers to create a habari 0.6 branches. This can obvioulsy fixed by branching for 0.7, reverting changes from trunk, and branching for 0.6. A pain, but will need to be done eventually. Otherwise, no zips will be generated for these plugins. > 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… See my answer re "-core and -extras" above :) > > > 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. Ditto. -- Ali B. / dmondark http://awhitebox.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
