-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Special:Version displays SVN version numbers for extensions out of $wgExtensionCredits, which seems to be done with $LastChangedRevision$ keywords in the extension's entry point file.
This produces massively incorrect numbers in many cases, since the entry point file is relatively rarely changed in non-trivial extensions consisting of multiple files. Updates to the body, class, i18n, and other files are not reflected.
If we're running on a SVN checkout of the extension, we could check the directory for its current revision much as we do for MediaWiki itself; this would tell us for instance if an extension's subdirectory has been updated separately from the core MediaWiki.
But if we aren't on a SVN checkout, or if individual files have been updated to different versions, this may or may not tell us anything useful.
Anybody have a suggestion on how to best handle this?
- -- brion
Brion Vibber wrote:
This produces massively incorrect numbers in many cases, since the entry point file is relatively rarely changed in non-trivial extensions consisting of multiple files. Updates to the body, class, i18n, and other files are not reflected.
Yes, this is the biggest argument against the use SVN keywords. SVN keywords exist mostly for compatibility with CVS, otherwise, their use is highly discouraged. If you need really want to use such type of version numbering, you should consider creating some code that runs 'svnversion' and use its output as the version number. 'svnversion' number also reflects working copies with mixed revisions and in modified state.
But 'svnversion' itself has other problems. It has to quickly recurse into all subdirectories in order to calculate the revision number. If run once every (standalone) application startup, it is ok... for not for a web application.
But the whole idea of using SVN version numbering for something outside revision control is still problematic.
If we're running on a SVN checkout of the extension, we could check the directory for its current revision much as we do for MediaWiki itself; this would tell us for instance if an extension's subdirectory has been updated separately from the core MediaWiki.
This brings another set of problems. Check this for example:
http://juliano.info/en/Special:Version
It improperly detects that my MediaWiki version to be "r368", that is, the version in *my* repository, not the official MediaWiki repository. I use Subversion in a distributed way, through SVK, so my revision numbers are private, have no meaning outside my repository. And the revision number in Special:Version includes a link to MediaWiki's viewvc log for revision 368, that means nothing in this scenario.
But if we aren't on a SVN checkout, or if individual files have been updated to different versions, this may or may not tell us anything useful.
The later problem is addressed through 'svnversion'.
Anybody have a suggestion on how to best handle this?
Forget using SVN revision number for anything outside revision control itself.
You may want to create a VCSTimestamp.php containing just:
<?php $wgVCSTimestamp = '20090101';
Have this file included in includes/DefaultSettings.php and this variable appended to $wgVersion, ending with something like "1.14alpha.svn{$wgVCSTimestamp}". Create a cron job that updates and commits a new version of this file once every day.
This way, it is much more friendly to distributed revision control. You may not know the specific revision of a checkout, but you can infer an approximate checkout time (and a range of possible revisions). That is enough to determine how old is a checkout or if it may contain some old bug.
People who replicate the repository will keep the same timestamp from the upstream repository, and it will stay frozen until the next pull, which is much more sensible.
Due to how MediaWiki's repository is structured, you probably want two timestamp files, one for trunk/phase3/, another for trunk/extensions/. For extensions, each one conditionally includes "../VCSTimestamp.php" if found.
Also, the solution still applies when you move from SVN to a DVCS.
Hoi, We are building a test environment to test MediaWiki and its extensions. We aim to provide information on what extensions can be expected to work in what environment. When extensions are found not to work, it should be possible to fix the problem. We found for instance that the Babel extension did not work on an older version of PHP, the code was backported and consequently it needed a new revision that it got.
Today I was struggling with the CrossNamespaceLinks. I tried to install the revision that is advertised on the English Wikipedia 37404 and it broke MediaWiki. An essential file was not part of the extension. I installed the extension without specifying the revision, it worked and it advertised itself as revision 37404.
I was building an environment with the new ie current Wikipedia software configuration. There are many valid arguments why it should be possible to reliably rebuild the software environment. One of them is to test the software. When installing an extension like CrossNamespaceLinks is a dark art, it is not valid to say in its documentation that it is stable software because the WMF runs it for a long time.
In my opinion the ability to be able to reliably install MediaWiki and its extensions, the ability to rebuild an Open Content environment is what demonstrates the quality of the software. This quality is what enables people, organisations to use MediaWiki in a stable environment. Providing this level of quality will bring more people to use our software, to help with the localisation of our software to enlarge the ecosystem that is building around our software and around the wiki concept.
My suggestion is to define and implement best practices for extensions and test extensions and their revisions for their functionality. Our testing environment is available for this. I will be happy to demonstrate it in Berlin. Thanks, GerardM
2008/12/31 Brion Vibber brion@wikimedia.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Special:Version displays SVN version numbers for extensions out of $wgExtensionCredits, which seems to be done with $LastChangedRevision$ keywords in the extension's entry point file.
This produces massively incorrect numbers in many cases, since the entry point file is relatively rarely changed in non-trivial extensions consisting of multiple files. Updates to the body, class, i18n, and other files are not reflected.
If we're running on a SVN checkout of the extension, we could check the directory for its current revision much as we do for MediaWiki itself; this would tell us for instance if an extension's subdirectory has been updated separately from the core MediaWiki.
But if we aren't on a SVN checkout, or if individual files have been updated to different versions, this may or may not tell us anything useful.
Anybody have a suggestion on how to best handle this?
- -- brion
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklb6VcACgkQwRnhpk1wk44MNACg2c0ztpocjHfsb5l+KxSu8e+I wXgAoMSrjFeTPzEnMY4904bxXZv+DiYf =GNqG -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Gerard Meijssen schreef:
Hoi, We are building a test environment to test MediaWiki and its extensions. We aim to provide information on what extensions can be expected to work in what environment. When extensions are found not to work, it should be possible to fix the problem. We found for instance that the Babel extension did not work on an older version of PHP, the code was backported and consequently it needed a new revision that it got.
Today I was struggling with the CrossNamespaceLinks. I tried to install the revision that is advertised on the English Wikipedia 37404 and it broke MediaWiki. An essential file was not part of the extension. I installed the extension without specifying the revision, it worked and it advertised itself as revision 37404.
I'm guessing this may be because the new file was added after r37404, but the file registering the extension (and providing the revision number) wasn't changed at that time, which means the most recent revision of *that file* is still r37404. Special:Version doesn't really report the most recent revision of the extension as a whole, but that of the setup file (IIRC).
My suggestion is to define and implement best practices for extensions and test extensions and their revisions for their functionality. Our testing environment is available for this. I will be happy to demonstrate it in Berlin.
Looking forward to that.
Roan Kattouw (Catrope)
On 3/25/09 5:16 PM, Roan Kattouw wrote:
I'm guessing this may be because the new file was added after r37404, but the file registering the extension (and providing the revision number) wasn't changed at that time, which means the most recent revision of *that file* is still r37404. Special:Version doesn't really report the most recent revision of the extension as a whole, but that of the setup file (IIRC).
Right, these version numbers are useless and in fact counterproductive because they're completely inaccurate. I strongly recommend they be removed if they can't be made relevant.
-- brion
On Thu, Mar 26, 2009 at 12:57 PM, Brion Vibber brion@wikimedia.org wrote:
On 3/25/09 5:16 PM, Roan Kattouw wrote:
I'm guessing this may be because the new file was added after r37404, but the file registering the extension (and providing the revision number) wasn't changed at that time, which means the most recent revision of *that file* is still r37404. Special:Version doesn't really report the most recent revision of the extension as a whole, but that of the setup file (IIRC).
Right, these version numbers are useless and in fact counterproductive because they're completely inaccurate. I strongly recommend they be removed if they can't be made relevant.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I've gone ahead and removed them from extensions in r48889 and removed support from them in r48890. Developers should instead use version numbers that make sense. We've had the 'version' parameter in $wgExtensionCredits since pretty much forever, use that instead.
-Chad
On 3/26/09 10:40 AM, Chad wrote:
I've gone ahead and removed them from extensions in r48889 and removed support from them in r48890. Developers should instead use version numbers that make sense. We've had the 'version' parameter in $wgExtensionCredits since pretty much forever, use that instead.
Thanks!
SVN revision numbers *can* be useful, but they need to say something useful. :) The per-file version usually isn't helpful, since the meat of the extension is usually in other files which change more frequently.
For MediaWiki itself we pull the SVN revision info for the whole directory, but you can only do that when you're actually looking at a checked-out working directory. If we want to do similar for releases or downloaded extensions, we need to find another way to store it...
(Extension versions are also complicated by having the branches for MediaWiki versions. This makes it harder to remember what you're looking at, but reduces the backwards-compatibility problems we had trying to keep trunk extensions working with multiple MW versions over long periods of time. Ahh, compromise!)
-- brion
Hoi, I understand how revisions work. How do you use version numbers with SVN, how are extensions to be supported in combination with SVN ? Thanks, GerardM
2009/3/26 Chad innocentkiller@gmail.com
On Thu, Mar 26, 2009 at 12:57 PM, Brion Vibber brion@wikimedia.org wrote:
On 3/25/09 5:16 PM, Roan Kattouw wrote:
I'm guessing this may be because the new file was added after r37404, but the file registering the extension (and providing the revision number) wasn't changed at that time, which means the most recent revision of *that file* is still r37404. Special:Version doesn't really report the most recent revision of the extension as a whole, but that of the setup file (IIRC).
Right, these version numbers are useless and in fact counterproductive because they're completely inaccurate. I strongly recommend they be removed if they can't be made relevant.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I've gone ahead and removed them from extensions in r48889 and removed support from them in r48890. Developers should instead use version numbers that make sense. We've had the 'version' parameter in $wgExtensionCredits since pretty much forever, use that instead.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 3/26/09 10:46 AM, Gerard Meijssen wrote:
Hoi, I understand how revisions work. How do you use version numbers with SVN, how are extensions to be supported in combination with SVN ?
To get useful SVN version information on the extensions you need two things:
1) The branch (trunk, or a branch associated with a MediaWiki release?)
2) The revision number the whole extension was last updated to. (This is not the same as any individual file's last-*changed* revision, which is all you get from the keywords.)
These can be pulled easily from a live SVN checkout, but if it's been distributed separately we need to perhaps add that info into what ExtensionDistributor generates?
-- brion
Thanks, GerardM
2009/3/26 Chadinnocentkiller@gmail.com
On Thu, Mar 26, 2009 at 12:57 PM, Brion Vibberbrion@wikimedia.org wrote:
On 3/25/09 5:16 PM, Roan Kattouw wrote:
I'm guessing this may be because the new file was added after r37404, but the file registering the extension (and providing the revision number) wasn't changed at that time, which means the most recent revision of *that file* is still r37404. Special:Version doesn't really report the most recent revision of the extension as a whole, but that of the setup file (IIRC).
Right, these version numbers are useless and in fact counterproductive because they're completely inaccurate. I strongly recommend they be removed if they can't be made relevant.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I've gone ahead and removed them from extensions in r48889 and removed support from them in r48890. Developers should instead use version numbers that make sense. We've had the 'version' parameter in $wgExtensionCredits since pretty much forever, use that instead.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
A standardized "version" file could go a long way to solving this issue. Could maybe make them auto-generated with an on-commit hook?
-Chad
On Mar 26, 2009 2:17 PM, "Brion Vibber" brion@wikimedia.org wrote:
On 3/26/09 10:46 AM, Gerard Meijssen wrote: > Hoi, > I understand how revisions work. How do you use... To get useful SVN version information on the extensions you need two things:
1) The branch (trunk, or a branch associated with a MediaWiki release?)
2) The revision number the whole extension was last updated to. (This is not the same as any individual file's last-*changed* revision, which is all you get from the keywords.)
These can be pulled easily from a live SVN checkout, but if it's been distributed separately we need to perhaps add that info into what ExtensionDistributor generates?
-- brion
Thanks, > GerardM > > 2009/3/26 Chadinnocentkiller@gmail.com > >> On
Thu, Mar 26, 2009 at...
Brion Vibber schreef:
On 3/26/09 11:20 AM, Chad wrote:
A standardized "version" file could go a long way to solving this issue. Could maybe make them auto-generated with an on-commit hook?
Hmmm, possible.
That'd be preferable over not providing any version information at all, which is what we're doing now.
Roan Kattouw (Catrope)
Don't know if it'll solve issue at hand, but we also have extension tags for a brave few: http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/
It definitely helped me to manage my installations (rolling back releases and so on).
One thing I thought it might be helpful for is for ExtensionDistributor to use those release tags.
Thank you,
Sergey
-- Sergey Chernyshev http://www.sergeychernyshev.com/
On Thu, Mar 26, 2009 at 3:53 PM, Roan Kattouw roan.kattouw@home.nl wrote:
Brion Vibber schreef:
On 3/26/09 11:20 AM, Chad wrote:
A standardized "version" file could go a long way to solving this issue. Could maybe make them auto-generated with an on-commit hook?
Hmmm, possible.
That'd be preferable over not providing any version information at all, which is what we're doing now.
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Was talking with Roan a bit earlier on IRC about this, and we got to thinking that an external version.php file could be defined per-extension. A new 'versionfile' param could be added to $wgExtensionCredits which points to the file. The version file could contain the numeric version, the svn version (which can be updated by an after-commit hook) and (optionally) a version name. More or less: do it kind of how we do extension i18n files right now, plus the hook to auto-update the info post-commit.
-Chad
On Mar 26, 2009 5:58 PM, "Sergey Chernyshev" sergey.chernyshev@gmail.com wrote:
Don't know if it'll solve issue at hand, but we also have extension tags for a brave few: http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/
It definitely helped me to manage my installations (rolling back releases and so on).
One thing I thought it might be helpful for is for ExtensionDistributor to use those release tags.
Thank you,
Sergey
-- Sergey Chernyshev http://www.sergeychernyshev.com/
On Thu, Mar 26, 2009 at 3:53 PM, Roan Kattouw roan.kattouw@home.nl wrote:
Brion Vibber schree...
I'm guessing this may be because the new file was added after r37404, but the file registering the extension (and providing the revision number) wasn't changed at that time, which means the most recent revision of *that file* is still r37404. Special:Version doesn't really report the most recent revision of the extension as a whole, but that of the setup file (IIRC).
Indeed. It would be much nicer if it could report the *directories* revision number. Does SVN have a keyword substitution for this? Does SVN allow scripts/plugins for this type of thing? That would by quite useful.
-- daniel
2009/3/27 Daniel Kinzler daniel@brightbyte.de:
Indeed. It would be much nicer if it could report the *directories* revision number. Does SVN have a keyword substitution for this? Does SVN allow scripts/plugins for this type of thing? That would by quite useful.
SVN does not have any such keyword, and the reason is the same as why doing this with a post-commit hook is not a good idea. See http://subversion.tigris.org/faq.html#version-value-in-source and a note at http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposa...
The proper way, IMO, is to do that with the sync script, or something similar.
-- [[cs:User:Mormegil | Petr Kadlec]]
Hoi, The Cite extensions is two distinct extensions in the same directory..
In order to get the issue of supporting extensions under control, best practices have to be defined and implemented. Not having such a solution is not really an option because it breaks the ability to reliably support MediaWiki for stable versions and it breaks the ability to reliably use the same MediaWiki environment as the WMF projects. Thanks, Gerard
2009/3/27 Daniel Kinzler daniel@brightbyte.de
I'm guessing this may be because the new file was added after r37404, but the file registering the extension (and providing the revision number) wasn't changed at that time, which means the most recent revision of *that file* is still r37404. Special:Version doesn't really report the most recent revision of the extension as a whole, but that of the setup file (IIRC).
Indeed. It would be much nicer if it could report the *directories* revision number. Does SVN have a keyword substitution for this? Does SVN allow scripts/plugins for this type of thing? That would by quite useful.
-- daniel
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
For extensions I write, I don't update the version number every time I make a change because it's too much, always editing (even if automatically) and checking in the main file.
I have this process for releases though where I use Makefile to create a tag and packages: http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/Widgets/Makefile
I know it's far from perfect, but better then not having any because I'll either forget to create a tag (or will not do that properly) or will not be maintaining downloadable versions (this will hopefully be unnecessary if ExtensionDistributor will support extension tags).
There is probably a solution that can be done within the code - something that makes all included PHP files override the version if it's later then in main file - something like this in main file:
*$myExtensionRevision = $LastChangedRevision$; function updateRevision($file_revision) { global $myExtensionRevision;
if ($file_revision > $myExtensionRevision) { $myExtensionRevision = $file_revision; } }
**include_once('subfile1.php'); **include_once('subfile2.php'); * *$wgExtensionCredits['parserhook'][] = array( ... 'version' => '0.2.'.$myExtensionRevision, ... } *
and then in subfile1.php and subfile2.php
*updateRevision(**$LastChangedRevision$**)*
Still, it's only a convention and not a universal solution, more over it'll only work if revision updated at least one PHP file. Also if extension doesn't include all it's files or uses AutoLoader, then it will not be reliable.
Thank you,
Sergey
-- Sergey Chernyshev http://www.sergeychernyshev.com/
On Fri, Mar 27, 2009 at 5:59 AM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
Hoi, The Cite extensions is two distinct extensions in the same directory..
In order to get the issue of supporting extensions under control, best practices have to be defined and implemented. Not having such a solution is not really an option because it breaks the ability to reliably support MediaWiki for stable versions and it breaks the ability to reliably use the same MediaWiki environment as the WMF projects. Thanks, Gerard
2009/3/27 Daniel Kinzler daniel@brightbyte.de
I'm guessing this may be because the new file was added after r37404, but the file registering the extension (and providing the revision number) wasn't changed at that time, which means the most recent revision of *that file* is still r37404. Special:Version doesn't really report the most recent revision of the extension as a whole, but that
of
the setup file (IIRC).
Indeed. It would be much nicer if it could report the *directories* revision number. Does SVN have a keyword substitution for this? Does SVN allow scripts/plugins for this type of thing? That would by quite useful.
-- daniel
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
"Sergey Chernyshev" sergey.chernyshev@gmail.com wrote in message news:9984a7a70903270737k8ae2e9dq9dbeb12d6dfe0a62@mail.gmail.com...
There is probably a solution that can be done within the code - something that makes all included PHP files override the version if it's later then in main file - something like this in main file:
[Code snipped]
This is basically what I do in my WikiDB extension [1]. There is a WikiDB_RegisterRevision() function, and all files in the extension call this function using WikiDB_RegisterRevision('$Rev: 114 $'), where the 114 will be automatically substituted using svn:keyword expansion. Check the files [2] to see it in situ.
[1] http://www.kennel17.co.uk/testwiki/WikiDB [2] http://www.kennel17.co.uk/testwiki/WikiDB/Files
Still, it's only a convention and not a universal solution, more over it'll only work if revision updated at least one PHP file. Also if extension doesn't include all it's files or uses AutoLoader, then it will not be reliable.
All true. In my case, I don't use auto-loading, all files are loaded on startup and I do not have any non-PHP files, so it works for me. However this is far from best practice and won't give terribly good performance on busy wikis, I suspect.
Perhaps we should add a "GetCredits" hook, to be called on Special:Version in order to get the credits info for the extension? If the hook is not found, or returns false, then the info in $wgExtensionCredits for that extension is used, otherwise the array returned from the function (which is in th same format) will be used instead. This would mean that the extension could use this function to include() all available files in order to get the revision number, but wouldn't need to include them on normal pages (thus avoiding the performance hit). Wouldn't solve the problem of non-PHP files being updated, but would solve the rest.
- Mark Clements (HappyDog).
On Wed, Apr 22, 2009 at 7:12 AM, Mark Clements (HappyDog) gmane@kennel17.co.uk wrote:
"Sergey Chernyshev" sergey.chernyshev@gmail.com wrote in message news:9984a7a70903270737k8ae2e9dq9dbeb12d6dfe0a62@mail.gmail.com...
There is probably a solution that can be done within the code - something that makes all included PHP files override the version if it's later then in main file - something like this in main file:
[Code snipped]
This is basically what I do in my WikiDB extension [1]. There is a WikiDB_RegisterRevision() function, and all files in the extension call this function using WikiDB_RegisterRevision('$Rev: 114 $'), where the 114 will be automatically substituted using svn:keyword expansion. Check the files [2] to see it in situ.
[1] http://www.kennel17.co.uk/testwiki/WikiDB [2] http://www.kennel17.co.uk/testwiki/WikiDB/Files
Still, it's only a convention and not a universal solution, more over it'll only work if revision updated at least one PHP file. Also if extension doesn't include all it's files or uses AutoLoader, then it will not be reliable.
All true. In my case, I don't use auto-loading, all files are loaded on startup and I do not have any non-PHP files, so it works for me. However this is far from best practice and won't give terribly good performance on busy wikis, I suspect.
Perhaps we should add a "GetCredits" hook, to be called on Special:Version in order to get the credits info for the extension? If the hook is not found, or returns false, then the info in $wgExtensionCredits for that extension is used, otherwise the array returned from the function (which is in th same format) will be used instead. This would mean that the extension could use this function to include() all available files in order to get the revision number, but wouldn't need to include them on normal pages (thus avoiding the performance hit). Wouldn't solve the problem of non-PHP files being updated, but would solve the rest.
- Mark Clements (HappyDog).
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Not sure it's worth it :-\ What's wrong with just giving version numbers that make sense, rather than relying on the revision number which isn't indicative of anything?
-Chad
On 4/22/09 5:54 AM, Chad wrote:
Not sure it's worth it :-\ What's wrong with just giving version numbers that make sense, rather than relying on the revision number which isn't indicative of anything?
It's indicative of the running version of the code, as long as it also tells you which branch to pull from. :) And of course as long as it's a relevant number like the revision of the extension directory...
-- brion
I probably have an idea of how to implement this using a bot (or post-commit hook if we want real-time data) and externals.
Essentially bot script should be checking the version of extension folder and generate and check-in an entry in another repository in the form like this:
http://extensionversioningrepo/trunk/OpenID/version.php
and write a Last Changed Rev from svn info http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID/something like this:
<? $wgExtensionRevisions['OpenID'] = 49664;
Then we'll use externals trick to map this into constant location withing http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID/ - something like:
svn propset svn:externals 'version http://extensionversioningrepo/trunk/OpenID/' http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID/
Then $wgExtensionCredits declaration in http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID/OpenID.se... have something constant like this:
$wgExtensionCredits['other'][] = array( 'name' => 'OpenID', 'version' => '1.8.4.rev'.$wgExtensionRevisions['OpenID'], ... );
This way every svn checkout and svn update will have extension version checked out from extensionversioningrepo
Alternative, more simple approach to this is to just store versions directly in repository as http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID/version.p... post-commit hook, but it'll double the revision number in main repository - it still can be done using a bot, in this case it'll only add one revision per run checking all updated versions in.
Hope this can be a solution.
Sergey
On Wed, Apr 22, 2009 at 12:14 PM, Brion Vibber brion@wikimedia.org wrote:
On 4/22/09 5:54 AM, Chad wrote:
Not sure it's worth it :-\ What's wrong with just giving version numbers that make sense, rather than relying on the revision number which isn't indicative of anything?
It's indicative of the running version of the code, as long as it also tells you which branch to pull from. :) And of course as long as it's a relevant number like the revision of the extension directory...
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 4/22/09 11:01 AM, Sergey Chernyshev wrote:
I probably have an idea of how to implement this using a bot (or post-commit hook if we want real-time data) and externals.
Essentially bot script should be checking the version of extension folder and generate and check-in an entry in another repository in the form like this:
http://extensionversioningrepo/trunk/OpenID/version.php
and write a Last Changed Rev from svn info http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID/something like this:
<? $wgExtensionRevisions['OpenID'] = 49664;
Hmmmm, could be maintained in tree this way, but IMHO not worth the trouble -- it's more likely to trigger merge conflicts and other annoyances.
Probably better would be:
1) Look up the actual useful revision from the working directory when we're running from a checkout
2) Also include that info into releases & ExtensionDistributor output so people who aren't working from checkouts will still get the useful versions, and look that file up if the SVN info isn't there.
-- brion
You mean, just run svnversion for each extensions' folder? this might be a good idea - it'll also indicate if we're running from checkout. Might also be a good idea to get the branch URL (e.g. trunk vs MW REL_X vs. extensions' REL_X or just branch path after http://svn.wikimedia.org/svnroot/mediawiki/) just for ease of debugging and stuff.
Sergey
-- Sergey Chernyshev http://www.sergeychernyshev.com/
On Wed, Apr 22, 2009 at 4:38 PM, Brion Vibber brion@wikimedia.org wrote:
On 4/22/09 11:01 AM, Sergey Chernyshev wrote:
I probably have an idea of how to implement this using a bot (or
post-commit
hook if we want real-time data) and externals.
Essentially bot script should be checking the version of extension folder and generate and check-in an entry in another repository in the form like this:
http://extensionversioningrepo/trunk/OpenID/version.php
and write a Last Changed Rev from svn info
http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID/something
like this:
<? $wgExtensionRevisions['OpenID'] = 49664;
Hmmmm, could be maintained in tree this way, but IMHO not worth the trouble -- it's more likely to trigger merge conflicts and other annoyances.
Probably better would be:
- Look up the actual useful revision from the working directory when
we're running from a checkout
- Also include that info into releases & ExtensionDistributor output so
people who aren't working from checkouts will still get the useful versions, and look that file up if the SVN info isn't there.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
"Chad" innocentkiller@gmail.com wrote in message news:5924f50a0904220554n32c3a4ecrd1cbc8cebcd74cb0@mail.gmail.com...
On Wed, Apr 22, 2009 at 7:12 AM, Mark Clements (HappyDog) gmane@kennel17.co.uk wrote:
[Description of WikiDB implementation of revision handling SNIPPED]
Perhaps we should add a "GetCredits" hook, to be called on Special:Version in order to get the credits info for the extension? If the hook is not found, or returns false, then the info in $wgExtensionCredits for that extension is used, otherwise the array returned from the function (which is in th same format) will be used instead. This would mean that the extension could use this function to include() all available files in order to get the revision number, but wouldn't need to include them on normal pages (thus avoiding the performance hit). Wouldn't solve the problem of non-PHP files being updated, but would solve the rest.
Not sure it's worth it :-\ What's wrong with just giving version numbers that make sense, rather than relying on the revision number which isn't indicative of anything?
It means a lot more admin overhead, having to update a version file (wherever it is) whenever you make a change, and also that you may often forget to bump the version number, particularly when making minor tweaks. This is not so much of a problem when you are in charge of the release schedule, as you can build a version number update into your release process, but if the code is being pulled in real-time for a repository, then this doesn't work as each individual revision needs to be considered a separate version and if you forget to update the version with every single commit, then the versioning becomes useless. This is really something that should be automated - humans are rubbish at this kind of thing!
For WikiDB I have adopted a simple approach. The version number is incremented when there are potentially incompatible changes made (or changes that require an update script to be run) and the revision is always the latest repository revision of the code. I am currently on v2 r177, for example. The revision number is not indicative of much, but it does uniquely identify a release and it does tell you whether you are running the latest version, and to be honest these two numbers tell you pretty much anything you need to know about the extension's version. The only problem is making sure that the revision is always up-to-date, which is solved (at least in this case) by the method I described.
- Mark Clements (HappyDog)
wikitech-l@lists.wikimedia.org