So are the files in the updates directory used going forward? That seems a little weird to me.
will be used instead of your root/concrete/ folder,
all the files in the root folders except the concrete folder are still used,
If the update package just overwrote your existing package you would lose all your themes addons and files,
By leaving the original concrete folder in situ, you are able to "roll back" to a previous version,
I hope that kinda makes sense..
Having the core go to the updates sturcture makes little sense. Decrease performance and uses more disk space that is not needed.
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...
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.
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, 184.108.40.206 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.
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.