I think UPGRADE.txt should be completed with instructions for minor updates (like 6.x -> 6.y).

It seems many Drupal users are having trouble with those frequent updates (for bugs and security), for them a very time consuming task due to the confusion between minor updates (6.x -> 6.y) and major upgrades (5.x -> 6.y).

The current UPGRADE.txt is in fact a procedure for major upgrades, with steps such as: switch to a core theme, disable all contributed modules, ensure that the versions of all modules match the new Drupal version, re-enable all modules, etc. For minor updates this is an unnecessarily long procedure.

See what some users are saying, for example:

So you don't disable all modules? You are skipping a lot of steps in UPGRADE.txt, such as disabling all custom and contributed modules.
I upgraded 6.6 -> 6.8 recently, and this was the most painful part... especially since disabling all modules requires multiple passes due to dependency issues, and you need to keep track of exactly which modules you need to re-enable after (and my site uses a LOT of modules).

(From the thread: Is a different approach in upgrading possible?)

I have exactly the same problem as Anil, it is so complicated and time consuming keeping Drupal up to date. In WordPress you simply click the update button and it gets on with it.
Really, the hassle of doing manual updates is a deal breaker for me. I'm more than likely moving to WordPress.

(From the thread: Updating a minor version requires so much grief?)

Etc...

In other more complete instructions, like Acquia Drupal's "Getting Started Guide" (from Drupal founder's company), or O'Reilly's book "Using Drupal" (from the Lullabot consulting team), there is not disabling of modules for minor updates (and it's only mentioned by Acquia as an optional step for major upgrades). A new version of UPGRADE.txt should reflect this.

Comments

I've just seen there is a Drupal issue that discusses this and other possible changes for UPGRADE.txt. They say for instance:

I think it would also be useful to distinguish clearly between minor and major upgrades, and to document them separately. Here I am considering a minor upgrade to be one from, for example, 6.5->6.6, and a major one to be 6.x->7.x. Specific areas that could be clarified in this way include:
1) is it really necessary to disable all contributed modules for a minor upgrade?
2) if you are only upgrading Drupal core, is it necessary to rerun update.php to handle custom tables and contributed modules, as is suggested by step 12 in 6.x UPGRADE.txt?
If people are supposed to upgrade promptly (and often), doing so needs to be as easy as possible. Looking at UPGRADE.txt makes it look like a much bigger production that it probably needs to be for minor upgrades.

(From the issue: Clarifications for UPGRADE.txt)

I agree, this could be made more clear. I remember doing this back when I first started using Drupal. It was more or less an experiment to see if going from 5.x to 5.y would break everything, and it didn't. That's how I learned..

Subscribing

I finally just wrote scripts to make sure that I didn't do anything like miss the copy of the .htaccess file or forget to do a new backup. Posted them here...

http://drupal.org/node/570594

I concur, the install instruction should be clearer. It would have saved me a lot of procrastination before upgrades :)

One of the mayor reasons I don't like to upgrade,
is because I have to go through al steps as described.

Really wondering if upgrading can be easyer for minor upgrades...

UPDATE
=====
What about this:
- http://drupal.org/node/570594

It's stil too complex for me, but might be a starting point for an upgrade module?

___________________
discover new oceans
lose sight of the shore

Yup.
So file a bug report on core for UPGRADE.txt.
And help with the documentation pages on point upgrades. Last time I looked they weren't up to scratch.

Is there a definitive instruction set for minor upgrades somewhere? Why not have ONE "Upgrade Central" with steps for performing major upgrades, minor upgrades, module/theme upgrades, etc?

I love the support I've gotten in the past from Drupal forums but at times wading through all the garbage and duplicated forums and modules on here is just ridiculous. Is there any kind of policing body on here to regulate all the duplicated effort?

Thanks again for all the support, guys. All I want to do is upgrade from 6.15 to 6.16 and I can't figure out how!!!

I totally agree with the comments about upgrades being a pain in the rear. I thought that installing a CMS would somehow make life easier for me. Duh!!

And what's the deal with deleting the entire sites/ folder from the server? It takes me forever to re-upload this folder and there seems to be little justification for doing so on minor upgrades and yet, here I am, waiting on the ftp client to reload all of the files...and waiting...

OK, so I do love drupal and I am here to stay for a few years IF there are plans to make life simpler for people like me.

In the mean time, if I get hit by a bus, my organization is kind of screwed as far as the drupal site. They would have to hire an expert to manage this thing.

Document, document, document...

I have also found the documentation relating to minor drupal core upgrades to be quite poor. I was hoping that drush might have some simplified steps, but it is not very clear either.
Drupal really needs to have a single simple mechanism for upgrading the core, modules, and themes. Can it really be that hard? I know that this is free and all, but without a critical mass of users, Drupal is dead.

As for the endless ftp time, have you considered copying the files to another directory and then moving them back? I know that this still requires ftp access (if you do not have telnet/ssh access), but it should be a bit faster.

Is there a simple instruction for minor updates?
I'm agree what other said that's why I'm stuck in old version 6.10 until now.

Subscribe

DBSLLC wrote:
> Is there a definitive instruction set for minor upgrades somewhere?

rikimaru0007 wrote:
> Is there a simple instruction for minor updates?

Yes, for example, as quoted in the core issue #295255: Clean-up the upgrade path: UPGRADE.txt, the following is an useful clarification by VeryMisunderstood (VM now):

I also state that you don't have to disable any modules because you are only moving up a minor version. You only have to disable modules when you are moving major versions. ie Drupal 5.x to Drupal 6.x because drupal 5.x modules will not work with drupal 6.x thus disabling them is a best practice as they will have to be upgraded too.
Going from 6.8 -> 6.9 is as simple as
put site in offline mode
back up your DB and files
delete all files and folders except the sites folder
upload all 6.9 drupal files and folders from 6.9 except sites folder
run update.php
The only files you will need to replace in drupal, is your robots.txt and your .htaccess. You only have to replace them in the new install if you've customized them.

Hi @all...

So I can confirm - nothing has to be disabled.

Simply:
put your site off-line:
make your backups (site & database)
delete the folders:
includes/
misc/
modules/
profiles/
scripts/
themes/
and the files in root (maybe except .htaccess -your custom files- etc...)
you don't have to delete sites/ - simply overwrite the containing files (it's just a readme an the default.settings.php)

Copy the contents of the drupal-6.24 package into the root folder (confirm the overwrites(should be 2))
Run update() -
And your done.

Sure I can not guarantee that this will work for you, too - as you could have some hacks in core modules etc etc etc.
But - it worked for me - and I had installed - and configured all this modules...:
admin_menu\
adminrole\
advanced_help\
backup_migrate\
better_formats\
block_class\
blocktheme\
cck\
contact_forms\
contemplate\
content_taxonomy\
ctm\
ctools\
draggableviews\
filefield\
filefield_paths\
filefield_sources\
i18n\
imageapi\
imagecache\
imagecache_actions\
imagecache_scale9actions\
imagefield\
imagefield_crop\
imce\
insert\
jquery_ui\
menu_breadcrumb\
menuless_nodetype\
mimedetect\
nodeformsettings\
nodehierarchy\
pathauto\
print\
qr_codes\
taxonomy_manager\
token\
transliteration\
views\
views_attach\
wysiwyg\
wysiwyg_imagefield

And - as some said before - I don't think that it is a good idea to tell the people that they have to disable their modules - have done that before (6.18 > 6.22) and THAT turned out to be a great pain in the x#x#!

Maybe someone could tell me why the module disabling should be necessary. I don't see it.

UPGRADE.txt is still wrong for Drupal 6, but was fixed for Drupal 7 (different sections for minor updates and major upgrades), with the issues:
#295255: Clean-up the upgrade path: UPGRADE.txt
#949102: Polish UPGRADE.txt