Bill Nottingham wrote:
If we are going down the road of providing absolute-latest-versions
older releases, perhaps not pushing it to prior releases until it's
actually been in wide use on the next release? So, you have, for example:
- new version 4.6
-> push it to rawhide, get testing
-> get new Fedora release with that version
--> get *even more testing*, make needed fixes
And only *then* do you push it to the prior releases, once it's actually
proven that it's not going to break things for the widest group of users.
It lets you not only use the rawhide adopters, who expect major change,
but the next-release early adopters, who also expect adjustments on moving
to a next major release.
The problem is that this translates to a LOT more work for us. By pushing to
both releases at the same time, we can build things together, do the
buildroot overrides together, queue things to testing together, promote them
to stable together. Doing things in the staged way would mean almost twice
the workload (especially in terms of time expense) for us. :-(
In addition, we already got 4.4.0 out only barely before 4.4.1 was released.
If we had staged it as you propose, we'd now be stuck with having to do one
of 2 things:
A. push 4.4.0 into F11 and 4.4.1 into F12. This means:
- we'd be working on 2 different releases at the same time, which would
stretch our resources quite a lot,
- F11 would end up with a KDE "update" which is already obsolete when
pushed, and in particular includes known bugs which are fixed in the bugfix
release that 4.4.1 is.
B. skip 4.4.0 in F11 and go straight to 4.4.1. This means:
- we'd be shipping the same release, but in one case as a big update with
many other related packages to update, and in another case as a bugfix
release. This also means 2 very different updates to prepare at the same
time and would also stretch our resources quite thin.
- the F11 update would either not be staged compared to the F12 4.4.1 one,
or the wait for 4.4 would be even longer than a month.
Support would also get more complicated with the 2 current versions in
circulation simultaneously. Right now, if something's fixed in F12, it's
also fixed in F11 and vice-versa, and we can in general expect our users to
all run the same KDE (unless they just haven't updated yet).
And finally, those F11 users who want 4.4 would feel treated like second-
class citizens for having to wait longer, those who don't want it just don't
want it at all, staged or not.
So I don't think staged updates are a workable solution (there's a reason
almost no maintainer works that way at this time).