Not sure how a change would help you now.

This also makes very hard to realize what has changed in the update and if it is important or not because of a lot of copyrights changes within the files.

Just to give you some heads up. In the release note, you see if the update is important or not. If it's called a security update, it is important - no excuses. If it is a regular update, you can delay the update a bit, but it still absolutely should be installed.
As long as you don't do any core hacks (which you must not do anyway), it shouldn't matter to you what changes were done in the update in detail. You're going to apply the update sooner or later anyway.

So imho, I see no reason to change our past behavior of changing the copyright in all files (SQL files included). If there are other reasons to not change the copyright date, we can evaluate it for sure, but this reason doesn't sound like a good enough argument to me.

@brianteeman :
If the process is bad (and here, it is), and there's a way to improve it in the future, it SHOULD be improved. Especially when it saves time.

@Bakual
Once the update is not about security BUT it changes the way our core business functionality works (i.e - just stupid example - form handling), then for the business/client it is also important to look into how that thing was changed without browsing through thousands of files that just changed copyright notice along with the rest of the update. Security updates are another type of the required code updates.

1. I dont believe the process is bad
2. Even if it was changed now it wont help you
3. You should be updating joomla through the joomlaupdate component

If you're talking about copyright statements in the extension manifest caches, honestly those caches shouldn't be in the SQL files anyway as they're automatically (re-)generated at initial install or update. So that's a non-issue.

If you're talking real structure or "critical" core data changes, agree in full.

@brianteeman

Even if it was changed now it wont help you

Can you elaborate on this? Because right now what you're saying doesn't make sense (at least not without context)

You should be updating joomla through the joomlaupdate component

Are you sure update component doesn't update the old files copyright? (making Joomla package files and server files inconsistent, so doesn't sound like a good thing)

@HLeithner can you please comment for J3?

Just another reason to change this - save time:
example:

• install update using downloaded package (because developer use git and they put files in git, so the company deployment tool can move it to the server)
• you want to see what was the changed logic between update on december and update on january and see if there's something you need to alter in your code
• good luck analyzing thousands of files, because copyrights changed in them too

That's a legal decision. Maybe @ronnikc can say something about this.

I would like to correct my comments above. I was under the impression that OLD update sql files would not be looked at again after they had been used. Seems that there is a bug that instead of being fixed people have change those old update files and they are being looked at

@HLeithner do we have any update to provide here or is the determination that it is a legal decision for this issue?

Since it's a legal thing I will contact Hugh Douglas-Smith about this.

@HLeithner I guess nothing is going to happen here now and this should be closed. Not my call though

Since we no longer update old files and set all copyright dates to the (hopefully) original date this issue can be closed because it's solved. @brianteeman thanks for pointing me to this pr again.

Well we dont update old files for copyright but the sql update files are not immutable as I constantly debate with @richard67