Christian Boos wrote: > Very true... "Worth a major upgrade and risk to break existing plugins" > would be my pet characteristic :-)
Right, upgrading to the next major release does have an associated risk. And it's not completely trivial to install two major versions of Trac in parallel, to test the upgrade prior to upgrading the live site (at least one version must be installed in a virtualenv, and IIRC it may interact badly with a globally-installed version, which makes life more difficult for people who installed through their package manager). Could we improve this? > In this case, how do you see the relationships between minor and major > releases? Won't we end up with either having a very short maintenance > period for a given major release or having more development branches to > maintain concurrently? Ah, long-term support, always a tricky issue ;) I had imagined keeping the same "policy": bug fixes on latest *-stable, enhancements, features on trunk, and possibly critical fixes on older *-stable. But I see your point: this would reduce our support to only versions between 6 and 12 months old. Or we would have to actively support more *-stable branches. This is probably a matter of personal preference, and how much effort each of the developers is willing to invest into supporting older branches. I'm sure Simon would want us to support older stable branches. Personally, I have close to no interest in more than one stable branch. Could we let those people who have an interest in older *-stable branches maintain them (including commit rights)? A stable branch would be supported as long as it has a dedicated maintainer. Note that I don't really have strong feelings about our release process, so if you want to try the -pre releases for some time, that's fine by me. -- Remy
signature.asc
Description: OpenPGP digital signature
