Firstly things first. > I have to admit that I find it puzzling why we waited around a week from > when we did started branching the plugins before discussing this. Also, the > original post[1] was posted about 5 weeks ago. I can't help but to wonder > why no one opposed this at that time?
For this, I apologise. Although i've been hanging out in irc for a while, i haven't really been following the mailing list, as i should. I only found out about the change when JibbyBot started posting changesets. Once again, I apologise. On Jun 25, 11:48 pm, Owen Winkler <[email protected]> wrote: > 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. Agreed. > > 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. Yay! This makes me happy > > 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. > Sure. Could you clarify how this differs from what i outlined above? I'm not sure i see a difference (which would be great), but i just want to make sure i'm not missing things. > > 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. Big +1 to this one. > > 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. Yup. Agreed. > > 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. I would have much prefered to external to a tag. however when i started doing this, there weren't any (useful ones) :) [snip] 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? Luke --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
