Renvoize, Martin schreef op do 05-06-2014 om 20:19 [+0100]:
I think there's allot of merit to Lars's suggestions and personally think the final approach to be the most sensible, allowing users to stick to a stable supported version without being forced to upgrade every 6 months in our case, to a .0 release.
I'm not opposed to the idea in general. There are just a couple of issues with it that would need to be resolved. So, for context, the current method is that there are three pockets: * squeeze-dev * squeeze * oldstable The 'squeeze' part is inaccurately named now. At some stage I plan to move it do something like koha-devel (though I like koha-dangerous), stable, and keep oldstable. We don't yet distinguish OS releases, and it's something I'd /really/ like to avoid. At this stage I do the build on a Squeeze chroot, and will do that until we either a) decide we aren't supporting squeeze any more, or b) it simply becomes too much hassle to do so for some reason, probably something to do with new dependency requirements that can't be built there. Squeeze-dev contains master, and is updated periodically. Squeeze tracks the current stable release and will get the .00 releases. It'll also go from, e.g., 3.14.xx to 3.16.00. Oldstable tracks the stable release series prior to the current one, so it usually starts with .06 or .07 releases, and never sees a .00 release. Essentially, the current practice means that you can err on the side of bleeding-edge, or you can be more conservative, but you're always supported. Now, the other approach is that we have koha-3.14, koha-3.12, etc. that depends on the current release of that series. We could also have a koha-stable, koha-oldstable for people who want to track things like the current way. However, the problems with this are: * We'll be building more packages, which is currently a fairly manual process (though I'm working on solving that, slowly.) * Keeping people current is harder. * What do we do with the koha package as it stands. I'll ignore the package building thing, it just needs me to sit down for a day or so and finish the script I'm working on to magically do everything and not make mistakes. However, having a collection of tracking packages would necessarily cause more overhead. But the keeping people current thing is more of an issue. If someone installed koha-3.10, they'd still be on 3.10, and it's not really supported. We have no way of prodding them to move to 3.16 or whatever when it's no longer receiving fixes for things, especially security thing. Now, they can have koha-common 3.10.02 installed if they want, and not upgrade it. There's nothing that /forces/ them to do that. But they are at least encouraged to. Essentially, the way I see the current system is that you have a couple of ways of ensuring you're up to date: be quite current, or be more conservative. We don't have to be everything to everyone, we can just do what is best for most of the people. Anyone who wants something different can always build their own packages, which isn't terribly difficult if you know much about Debian. We'd also have to figure out what to do with the existing Koha package. It's always been my plan that installing that would give you a preconfigured system, but a) I don't think I'll ever get around to doing that, b) it's harder than it seems, and c) no one else seems to want/need/care about that either. So stripping it out and replacing it isn't a big deal Now, I'm not writing off the more fine-grained method. It would solve a couple of problems, for example we wouldn't need to have pockets in the repo for the different versions, so that complexity is lower, even if overall it'd be higher. But I think we do need to carefully consider what problems we're trying to solve, are they really problems, and will this solve them without introducing more? -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF