Point one: I’ve seen a few projects that release all the files for an update. If its only one file, I agree that should be made available, in the case of 1.5.1.3, it was 3 or 4 files that had changed all in different directories.
Point two: Your point one and two are the same. Service Pack 1 for Windows 2003 was ~350MB, that practically IS an operating system.
Point three: Disclosing the full extent of a vulnerability as soon as you release an update still allows people to exploit those who have not yet updated. People don’t update within 5 minutes of the update being released. Some don’t for weeks after. Believe it or not, there are still people running 1.2
[self edited as same as above] – I just type slower 🙂
Ok, so they may be in different directories, but it’s still a hell of a lot easier to replace four files than the backup and reinstall the whole damn system. It should be possible to create a zip with the relevant number of directories with the files in them, so that when one uploads the set of directories, the FTP sees that they exist and says, “hey, there’s already a file here with this name, want to replace it or keep it? this directory already exists and. . . has a file with this name, want to replace it or keep it, or make a new directory?” and so on. Most FTP clients I’ve used are smart enough for that. . . . And failing that, most users who have enough technical knowledge to have installed the damn system in the first place are knowledgeable enough to upload four files.
So again, why isn’t it possible to just replace the four affected files?
Another reason might be so that when somebody downloads the latest version to install, they dont’ need to download the main archive and 3 patch archives ie. 1.5 (full) -> 1.5.1 (patches) -> 1.5.1.2 (patches) -> 1.5.1.3 (patches)
How about next time, you release a full package, and an upgrade only package with details as to which files you need to replace…
That would make me happy!!!
Thread Starter
reven
(@reven)
I agree with libcat: the number of files or directories is not a point. Just compare to the upgrade instructions in the codex: you have to delete two folders, delete all files in the root directory except the config file, then download and extract new version to the suitable directories…
And this is easier than replacing 4 files in different directories?
Thread Starter
reven
(@reven)
Oh, come on ryanduff. How about a ‘latest’ package and then the update packs? Shouldn’t be too hard.
I will say with hispeed connection, it’s relatively a short process to upgrade the entire structure. However, I’m now working with 3 wp installs, and would like to think that I will find more uses for WP, and in that case, doing multiple full upgrades can be tedious. However, with the forum, and discussions like this, the resources ARE there to learn what files have been changed.
That is execssive and was meant for major version upgrades where files have changed, moved, been removed and not for minor upgrades where only a few files need to be replaced. It can still be packaged as a full release (only somebody on a 14.4Kb dialup account will notice slowness when downloading a 290kb file.)
Maybe the docs team as well as matt/ryan need to look at updating release notes to say upload xxx file(s) to /blah/ and you will be patched.
Thread Starter
reven
(@reven)
No, I meant that you could be given the option to download either the latest full version or the update packs from the version you have. That isn’t too hard to do. The download page could be left as is and a ‘patches’ link could be added to the sidebar.
The patches page can contain all the patches since the latest major release, for example: 1.5 -> 1.5.1.3, 1.5.1 -> 1.5.1.3, etc.
If it seems so difficult, then why upgrade? No one is “forcing everyone to reinstall the whole thing.” And while I agree that it would be nice to have a zip of the changed files available, downloading the whole thing and extracting the changed files is not even time consuming on dialup.
I would very much like there to be explicit instructions re: upgrading from recent releases, so that I don’t have to feel as though I must delete and re-up everything outside of wp-content. Other people feel similarly, and references to the changelog in the codex really aren’t sufficient from a user-friendliness perspective. If the canonical download’s readme says “to upgrade, delete everything except stuff that you’ve changed and then replace it with this new stuff”… well, that’s not really speaking to the masses.
Case in point: this most recent time I accidentally overwrote my custom smilies. There was no reason to overwrite wp-images for a 1.5.1.2 -> 1.5.1.3 upgrade, but I forgot about my smilies at the time and just blew them away. Had the changelog been included in the readme, and been phrased as instructions and not developer-centric information, it would have been a boon.
Given the current size of the WP download — a 360K zip — downloading the whole thing just for upgrade purposes isn’t a problem. What is a problem, however, is the confusion that comes from having all those unnecessary files. An official 1.5.1.2 -> 1.5.1.3 upgrade, like angusman’s, which didn’t contain unnecessary files, all would have been groovy.
I’m not complaining so much for my own sake … I’m more concerned for the sake of those whom I introduce to WordPress. People who don’t read support regularly or even see new release announcements. It’s one thing for me (/we/the media/etc) to give our WP-using friends a “heads-up!” when we see that security updates are available; it’s a completely different kettle of fish if, duly alerted, said people are unable or are too intimidated to successfully update for themselves.
I would rather download a new version, delete the old files and upload the new version as soon as a security issue is found than wait the length of time Microsoft wait before releasing “patches”.
The simple fact is that we’re not going to make all people happy. We can try, and fail miserably; or we can set an acceptable baseline and stick to it.
Everyone here — everyone — is a volunteer. We often have things we’d much rather do than build a zip file of just the changed files.
Think of it this way: by having only one official ugprade process, we are making it easy for new users to know –and remember — what to do. “Oh, this is just like installing it from scratch!” We need manage only one download location; we need point users to only one location; and we need maintain only one set of instructions — that is a committment to user friendliness. Now, the contents of said instructions could use some attention. Feel free to contribute or discuss ways to improve it.
If we start providing patch level downloads, we’ll complicate the download page. For every person we make happy with patch downloads, we’ll confuse a new user. We literally cannot win this argument. Accept that a decision has been made, and that it is unlikely to change.
This is the fourth or fifth thread on this issue. If you feel strongly enough about patch downloads, please construct them, make MD5 sums of the individual files, as as well MD5 sums of the zip files, and send them to me. Post the MD5 sums of the individual files and the archive file somewhere so that I can compare your posted results with my calculated results. It would be extra helpful if you could send the files to me in a GPG-signed email, so that we have a full audit trail. Please indicate in your email whether I can expect additional patches from you every time a new release occurs, or if this is a one-time project for you.
I’ll see what I can do to get them posted for download. I make no promise that any such patches will be posted, since I don’t control this website. I can only promise to try.
Note that people who really want patches can and should investigate the Trac and Subversion instructions.
