Thanks for considering these ideas.

Your point about file-formats is a good one. I wrote up an answer here because it’s a complex problem.

Yes, I was thinking along the same lines for retracted versions.

In my vision, one would keep the bidirectional diffs around, unless the user requested to delete them. When you’ve got disks ranging from 80 Gb to a Terabyte, a dozen extra Mb over a year is probably not going to be noticeable. And, as a user, I’d be much happier knowing I’ll never lose my stuff due to an upgrade. Maybe I’m weird, but I keep the old versions of all the software I rely on.

My wife also pointed out over supper last night that one should check whether or not the software is supported by the OS you have when upgrading. For instance Delicious 2.0 is I believe Leopard only. People with Tiger should not have the option to upgrade to it because it’ll break something.

We’ve discussed the version downgrading, but there’s lots of concerns about backwards-compatibility of file formats and various problems that could arise in going backwards. Generally stuff isn’t forwards-compatible, you know? Any thoughts on that? Forcing the developer to explicitly define rules for going backwards to each version kinda sucks.

I like the idea of downgrade versions. I sure have made some bad releases that I would like to retract. I’m thinking a list of retracted versions at the bottom of the feed like so would work:

aslkdfjasl;kdfjal;ksdjf
3.0

If you changed something in the archive, it’d certainly have a different DSA signature since its SHA hash would be different. This means that Sparkle would have to keep around the update archive to check against all the time, which is kinda silly.

The harness idea is rather ingenious, actually. I like. It’s esoteric enough that I’m not sure I’ll get to it, but I like it.

And yeah, I’ll notify by Growl. I don’t know if by email. It’s easy enough, I guess.

Thanks a lot for your thoughts!

Of course, for people who really care to be asked, “the user can require a confirmation step using the Application’s Preference Panel”. I’m certainly not advocating overriding the admin password if the user is not an administrator though.