View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008609||mantisbt||bugtracker||public||2007-11-26 05:06||2007-11-27 08:54|
|Summary||0008609: Because of (closed) "0008063: mantis_version shouldn't be in the configuration file"|
I saw this issue by checking the history of last pre-release RC3 and couldn't comment on it, thus I add a new issue, because it is (or would be) one.
In general you're right, that the version of the software is something, which does not change, but if - as in my case, you have to patch something , which is not fixed, but annoying in productional use or add e.g. a new functionionality.
Then a slightly changed version (or something like that) should depict the difference to the release version.
Hope for a general agreement - how can this be achieved with current hidden version information
BTW: please link this issue to 0008063
|Tags||No tags attached.|
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:
shown on footers: 1.1.0+SVN
I think, its not solved, but a possible solution is given. Thanks to Giallu