Update version and copyright to 2025, to better manage development versions

[cary-rowen]

Link to issue number:

n/a

Summary of the issue:

Just update the version to make it easier for users to distinguish between the current stable version and the development version.

Description of how this pull request fixes the issue:

Just update the version number and copyright year.

Testing performed:

Manual testing

Known issues with pull request:

n/a

[pauliyobo]

I'll use this PR to raise a question.
It looks to me like we're using a calendar versioning scheme, though it's unclear at least to me, which convention we're using.
Typically, we should increment the version number before a release. Since the scheme we're using is calendar versioning, I'd assume the scheme would indicate a release date, or a release cycle. Since we have none of the above, wouldn't it make more sense to just update the version number with the release date after a tag is created?
This would actualy reduce the number of places we'd have to keep in sync.
For snapshot builds, version numbers are relevant, but probably not as much, since they are snapshot builds. I'd argue the most important information in this case would be the commit hash.
@cary-rowen and @mush42 what do you think?
For context:
Calendar versioning

[mush42]

@pauliyobo good idea, but I'm leaning towards making version tags more user friendly and easy to remember. This can save us a lot of trouble when dealing with bug reports

[pauliyobo]

@mush42 version tags for final releases can keep the same calendar versioning scheme, they'd just follow the release date, such as 2025.01.04, or 2025.1.4
For development versions, honestly anything works.
We could leverage commit short hashes, which are typically 7 or 8 characters long, and users could just copy them before reporting the issue.
I don't think this will cause a lot of confusion, especially if we're going to distribute stable versions elsewhere, such as what was suggested in #294
But let me know if there's something I'm missing or not understanding.

[mush42]

@pauliyobo we can go with any option we deem suitable, but try to avoid user confusion.

[pauliyobo]

@mush42
Of course. The only thing I'm saying is, that it might benefit both users and us in the long run.
We can absolutely keep whatever convention we have now, and if so, I'd like a clarification on that.
When trying to identify on which version an issue can be reproduced, having just the version number helps, but it doesn't help much when for example the latest tag is a few commits behind from the latest build. A notable example can be the versions before 2024.1. Conversely, incrementing the version number without actually releasing can potentially cause the same problem. It is probably not a big deal, but worth mentioning all the same.
If we had something more precise on development builds as well, it would help us determine how out dated the version is.
Note that we do also have a releases page, so I don't necessarily think that handling development builds differently in terms of
version identifiers would cause much confusion.
Of course it is just it, a proposal. In the end if there are better ways to handle this situation I'm more than happy to change approach.

[mush42]

@pauliyobo proper cal versioning lgtm. Let's go with that then.