I *wish* it made a difference. I did an upgrade am an left with a
host

of fc10 packages because the fc11 ones weren't considered newer.
For example people with updates-testing enabled on fc10 got a
non-upgraded yum because the versions were the same (except for

fc10/fc11) and it stopped working because python went from 2.5 to
2.6.

That's messed up. We used to check just before release time that this
situation never occured.

^^^^^

No, that's not entirely true. The full story is from the book "What
sucks

about Fedora".
There used to be regular runs of the upgradecheck.py script from the
Fedora Extras era, which mailed the fedora-maintainers list (and later

fedora-devel list), and later the upgradecheckspam.py script which
mailed

package owners directly. That helped with getting upgrade problems

fixed, but it wasn't part of any release policy to make sure all
upgrade

path violations would have to get fixed.

Then with the switch to koji+bodhi a few package owners complained
loudly
about false positives that were caused by pending builds, which were
not
found in the master repo yet. A few other package owners jumped upon
the
train and questioned the usefulness of the script, since they were
of the
opinion that breaking upgrade paths the way they did it with updates-
testing

and stable updates would not be considered a problem.
Even later there used to be another script that queried koji for more

accurate package release versions, but it has never been run
regularly,

not even prior to the next Fedora release.

It should probably be added to the rel-eng
release checklist if it isn't there already.

Does rel-eng have any interest at all in avoiding some upgrade path

problems? I don't see that. Running a script to catch _some_ issues
would

be tons better than not running a script at all. The problem is not

limited to some people upgrading from F10 updates-testing to F11
without
updates-testing. There are still packagers who bump %version or
%release
in old dist updates without considering the consequences with regard
to

dist upgrades. And in Rawhide? Just because a packager doesn't track

Rawhide for some time should not imply that files in "devel" cvs
become
older than in the other dist branches or that updates for released
dists

get ahead of builds in Rawhide. The freeze only adds to the problem,
because packagers can push upgrades for old dists while the unreleased
dists remains frozen. It's also simply a crap decision if packagers

quickly mark F10 updates as stable while the corresponding F11
update has