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
Drupal issue on UPGRADE.txt
I've just seen there is a Drupal issue that discusses this and other possible changes for UPGRADE.txt. They say for instance:
(From the issue: Clarifications for UPGRADE.txt)
I agree, this could be made
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
Subscribing
Even with updated instructions, there are still "gotchas"
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
I concur, the install instruction should be clearer. It would have saved me a lot of procrastination before upgrades :)
Subscribing
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?
Yup. So file a bug report on
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.
Sooooo
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!!!
What a pain
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...
Central management of Drupal software upgrades required
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.
Subscribe
Subscribe
In short
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
Subscribe
Simple instructions for minor updates
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):
Modules don't have to be disabled! 6.22 > 6.24
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, fixed for Drupal 7
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