The current method uses the MANTIS_VERSION constant, which is set in core/constants_inc.php - it can still be overridden by changing that file, it's just no longer easy to do by accident like it was before when it was a configurable variable.

The problem is it will get overwritten each time one upgrades the mantis code...

(to add to giallu)"... and this without a warning.

When committing this issue, I guessed, that this would be not easy to solve .. If I'm generally right and follow the rules of this project, overwriting something in ./core directory is not allowed per edict :-)

Is it possible to generate a WARNING, which could be recognized by the administrator to decide, if the new installed version (number) should overwrite the locally last set one?

brody, I don't think you're fully understanding Giallu. The point is that when you unzip the latest release of Mantis, overwriting your existing install, then you will lose any customizations to core/constants_inc.php, and since this is not done through the web, there's no possible way to generate warnings for this.

However, with any customized installation, whether you update Mantis by unzipping a release tarball, or by updating from SVN, there will necessarily be a need to re-edit something, either by reapplying diff patches against the new tarball, or by resolving conflicts in SVN.

During this process of 'fixing' the update to work with your custom changes, it should be simple and unproblematic to update the constants_inc.php file appropriately to match the release version along with your changes. IMO, there shouldn't be an automated way to handle this, simply because you can't possibly expect the system to guess things correctly, so the best action is to simply require a real human being in the know to look at the problem and decide how to solve it.

Unless there is a real issue with using a constant, like actually breaking things, then I am inclined to just mark this resolved. Please enlighten me otherwise.

I think the issue here is what I pointed out in the related bug: we are now overloading the mantis version field to convey the MANTIS_API_VERSION semantic.

Of course plugins (and their authors...) are now happy because administrators can't pretend to be using a different mantis version, but administrators are less happy because they can not easily override what is shown on the pages: I think we should consider giving them back this "feature".

If you agree, I can see at least two possible approaches:

1. let the admin configure a "extra-version" field, either as a custom define or a configuration parameter. this would be shown after the current version like in:

version: 1.1.0
extra-version: +SVN

shown on footers: 1.1.0+SVN

2. create the version string in a function overridable via a custom one.

@jreese:
What you described in detail was meant be my first sentence. Nevertheless I think giallu's last comment points to a good solution for all involved.
You get (or rescue) the MANTIS_API_VERSION, which is important for all the addons and if one, as me, have to change (maybe temporarily) the behaviour of mantis in local installation by writing code (and not only customizing), could show that its not the origin release. In most cases the API will not be changed by these private changes.

I think, its not solved, but a possible solution is given. Thanks to Giallu