Rahul Sundaram wrote:
Robin Laing wrote:Tom Horsley wrote: <SNIP>In fact, while we're at it - never have another "release", just keep upgrading rpms forever with individual packages being released, but nothing called a whole distribution having a release. Individual rpms just get marked obsolete and replaced with new ones in the ever updated lists. Now *that* would be a Knight in shining armor! Fedora 7 is a mere feeble imitation in comparison :-). [Just don't ask me to do any of the work :-].Now, this is a great idea. No more worrying about upgrades or do I have enough time before the next release to make all the changes. What about he secondary repositories for things that will never be in Fedora proper that you have to wait to be released.I would like to see Fedora 7 or Fedora 8 become just Fedora and then no more 6 month release dates. Just updates to what would be the next release.QA is a nightmare with a rolling updates model for the whole distribution. There are some changes that are just too intrusive to put in as updates. Moreover even distribution with rolling updates have "releases" which are snapshots of the repository packages which can be used as a starting point for retail distribution and a starting point.Rahul
Rahul,You make my point. As a user I hate the idea of having to do a new install every six months or skip a release and it is once a year.
I would prefer that there be an easy upgrade path throughout the year. Thus, the developers can make changes to Z application and have that go out to the Fedora crowd. Now if there is a major change, such as udev, then this can get complicated but not impossible. It is possible to upgrade from FC4 to FC6, I have done it. Now if it was FC4, FC4.1, FC4.2 ... FC6, then the upgrade would have been painless and happen with normal yum updates. Is yum/rpm smart enough to handle this?
I can agree that a major change could be a real headache but if the changes are grouped, lets say the move to PATA as part of the kernel upgrade, then most applications can be updated at the same time. Now, I remember doing a kde update that was massive so why not a change like that. There is still the testing branch to work things out on.
Even a new install isn't complete until you update all the packages that have changed since the distribution came out. Even this creates calls for re-spins (correct term?) of the distribution to save the update time. Again, this is resolved by more but smaller updates to the current build status. As for spins, they become dated instead of versions. Thus FC 8 could become Fedora.20071001 and when it is re-spun it just takes the new date Fedora.20080115 as an example.
Now I know when the issue was spun and that I may need to get a larger number of updates if I get an earlier release.
Is the present system a deal breaker for Fedora? With the loss of legacy support for older versions, it is looking more and more that it could be.
-- Robin Laing
