luke wrote: > > I am a habari user, and plugin writer. I haven't worked on core code, > although i have code dived (diven?). We're basically starting to roll > out habari to most of our clients. It's becoming our software of > choice. That's where we are coming from.
If this is the case, then having a sane way to maintain plugins for clients who, for one reason or another (usually "don't want to pay to upgrade core"), won't upgrade Habari. Let's just correct this one thing right now: Letting trunk whither is a mistake. We talked about theoretically back when we started this conversation, and that's the conclusion we came to. It was wrong. Let's move on. 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. Trunk is for new development. Unless you are a dev for the plugin, you don't use trunk. Branches are for maintaining security releases for old versions of the plugin. We have 0.6 and 0.7 branches for many plugins now. The main reason for this is that trunk code, if it is the latest 0.7 version, will not work on 0.6. 0.6 is our stable release version of Habari. If a user comes to download plugins for their stable release install, they're going to want 0.6, not 0.7/trunk. Branches can also be for experimental work. That's fine. But we - plugin developers - also need to agree on a single place from which security-supported updates will derive. In plugins for 0.x versions of Habari, this isn't going to be as important as for major versions. Major versions of Habari may linger for much, much longer, and the plugins for older versions will need to be maintained while the new ones are worked on. If you want to be forward-thinking, think in that direction, please. But people who want stable releases really shouldn't be downloading branch versions of plugins either, because that's where the work goes to produce a release. If someone wants to test a preview release of a plugin, they can grab it out of the branch for their version of Habari. Pre-release code should not be tagged. When you tag a plugin, that's the trigger for the system to produce a distribution package of the plugin. No, this system is not built yet. But my thought is to have a build system that will produce packages of anything tagged with a version number matching our x.x-x.x scheme, and anything in a branch with a version number matching that scheme. A new page somewhere on the site would list versions available of a plugin. It would be very clear: "This is the stable release for 0.6" "This is an in-development (branch) release for 0.7" We might even produce a zip of trunk for convenience, but if you're using trunk code, you should probably pull it from subversion. A lot of this organization is pre-planning for when we get to a 1.0 release, and we need plugin branches that work with one or the other because we'll have to support old major versions of Habari that have been included in long-life distros. That's a nice goal, right? We need a plan for that. This is part of that plan. Right now it looks confusing because the changes in plugins/core aren't big enough. But if you imagine the timeline much farther out, hopefully this will make more sense. Starting now, setting things up that way now, will reduce pain from transition later when it'll matter more. If you're updating plugins with svn:externals, this is all going to seem like a pain in the butt. But trust my experience from doing this in the past -- you do not want to do this anyway. If a plugin's trunk goes off the deep end, and you update to it, you will be in for a world of pain getting things back. Instead, if you must, external to a tag (or at worst, a branch) and then re-point your externals when you update. Yes, it's a pain. That's why I'm saying "don't do this". I'm sure someone can write a script (and this sort of thing could be part of a plugin -- I've seen source for it) that will update plugins to their latest stable tag/branch, and that will be a better solution. For people complaining that this doesn't work like Habari core does, apart from the trunk issue that I've conceded above, it's remarkably similar. The only difference between this and the makaanga branch is that the plugin makaanga is simply a specifically-named (by version) branch in the repo. That's it. Dare I say it... Drupal has been using this scheme for developing their contributed plugins for some time. If you look at any of the Drupal project pages for their modules, you'll see more or less what I've described. The only differences in the plan as outlined from what Drupal does are that Drupal uses CVS and they are able to mark branches as recommended for use with major core versions. This is mostly due to limitations of CVS. Tagging a copy in svn will do the same thing for us. I'm not saying that their system is perfect and ours needs to be identical. What I am saying is that you can look at Drupal as a working model, and any other speculation as to what might work better is just speculation. As to the issue of plugin developers who have updated trunk to 0.7 without branching for 0.6 -- YOU HAVE SCREWED UP, but all is not lost. Figure out where your plugin was last 0.6-compatible, and branch the code to an 0.6-y.x branch from that revision. I think that we can all agree that some system is needed to address the issue of compatibility between branches. My premise is that it's going to be more important for users to find and use the correct version of their plugins than it is to reduce the pain of a couple "svn switch" calls. Yes, it's going to expose lots of out-of-date plugins. No, I don't have an immediate solution for plugins that would continue to work for future versions of Habari even if they're not updated in branches. I guess what I'm saying is that any system is likely to have some weakness, and what I've seen suggested in this thread so far more resembles a plan you would assemble for a single core open source project than a collection of supplementary collaborative projects. The solution for -extras is by necessity likely to be different than what you're used to if you've worked only on core project repos. To that end, the initial planning (which few others deigned worthwhile to participate in at the time, I'll add) was modeled after a generally successful implementation of that concept. Please keep this in mind as you make suggestions for the betterment of the extras repo. 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 -~----------~----~----~----~------~----~------~--~---
