I would think the updates would go in the \concrete directory structure sense this the location for core files.

Having the core go to the updates sturcture makes little sense. Decrease performance and uses more disk space that is not needed.

Some people do in fact delete the root concrete directory and replace it with the updated one, the system isn't slowed down by reading the updates/concrete/ folder because it just ignores the root/concrete one,
If you are concerned about storage space on the server then you do have the option of replacing the root/concrete one,
Many of us prefer to be able to roll back if we detect a problem with a recent update or incompatibility with our themes or addons,
The choice is yours but be careful that you don't break your database...

I can see both ways. The good part is the code still only maintains two levels, Core and Custom.

Hmmm..it makes sense from the viewpoint of "I want to be able to rollback"...but in practice, it is not the best way, in my opinion.

The /concrete directory should be the "active" one.....the "rollback" directory should be the OLDER version, moved to a "rollback" directory or something.....as it stands now, I have to tell my site maintainers to go to the /updates/x.x.x.x directory and use that....but OH NO! we had to rollback, so now I have to tell them to use some different x.x.x.x directory after the next few updates.....hard to maintain!

The /concrete directory should ALWAYS be the active one, otherwise one has to "know" what the active one is at any given point.

I guess this could be fixed by moving/deleting/sym-linking directories, but it becomes "not as easy" if you have to do that.

Symlinking isn't best, anyway... think of the poor Windows users.

OK that's long enough thinking time.

I just realised also that as I think of the /concrete directory as the 'system core' I'm incorrectly copying stuff out of there into /single_pages and /blocks to base stuff off from time to time. This means that I'm creating stuff based on possibly incorrect versions (like V5.4.x) of code at the time of creation where really I should be basing it off /updates/concrete_some_version_x.x.x.x.x/blocks/whatever.

That's highly counterintuitive to me, also.

It'd be nice to at least see 'delete older updates' in the dashboard to wipe out e.g. 5.5, 5.5.0, 5.5.1, 5.5.2, 5.5.2.1 and older versions where you're happy with the way your site's running.

I have some small sites that are over 1/4GB in size which is ridiculous and you really shouldn't need to SSH into the server to go find and delete the cruft to e.g. keep your backup files sizes sensible. As a platform C5 should be doing it or allowing the admin to with ease via the dash.

Sorry to bring this old thread back... I don't like to do that, but I actually searched for and found it based on myself thinking the same thoughts.

Pendragn and surefyre both bring very valid points to the table -- the same that I was thinking.

I'm guessing the "If it's not broken, don't fix it." mentality applies a lot to this situation, but I have caught myself pulling files to override out of the wrong (/concrete) directory many times, even knowing that there was an updated version in /updates/x and just not thinking.

I really like the idea of /concrete always being the current, active version, and I'm guessing that if you were to start from scratch, that would be the case?

Just wondering if there is any thought to address this in the future.

Thanks!

I am having an issue with my hosting organization, in that they say I have excessive directories in my account. When I follow their method of checking this, I find all the previous update directories in their listing. So, if I was to weed out unneeded directories, can i just delete those associated with previous updates prior to the current one? How about the first update in the updates directory, or the original install files? IF the latest update has everything I need do I need to keep the original?

There's actually a little bit of discussion about this in the 5.7 github. If you guys would care to share ideas / concerns:
https://github.com/concrete5/concrete5-5.7.0/issues/95...