Last modified: 2013-03-13 19:05:08 UTC
They're going to be useless in Git. Need to come up with a new versioning scheme.
(In reply to comment #0) > They're going to be useless in Git. Need to come up with a new versioning > scheme. Or do we really need to keep them at all? They have some use, but I can't really say I've ever used [1] for anything specifically, and similarly for [2] [1] http://en.wikipedia.org/w/api.php?version [2] http://en.wikipedia.org/w/api.php?action=paraminfo&modules=parse
It would be nice to have some kind of versioning on our public API so people can detect incompatibilities when they exist.
We could do that using a global array just like we did to track stylesheet version. Or define a constant for each API class much like Parser::VERSION or Parser_LinkHooks::VERSION.
(In reply to comment #3) > We could do that using a global array just like we did to track stylesheet > version. Or define a constant for each API class much like Parser::VERSION or > Parser_LinkHooks::VERSION. I'd much prefer the latter. As long as we can define a clear policy for how often and when the version numbers should be bumped.
(In reply to comment #2) > It would be nice to have some kind of versioning on our public API so people > can detect incompatibilities when they exist. Although the previous svn:keywords did not provide that information, that was just a simple "last rev modified" number. Right now this bug is just to remove them. We could open a feature enhancement ticket for that other, although I personally never found that needed and release notes seem to be more useful for breaking changes. If we create an API module to programmatically be able to export the version of an Api module, the it could be useful to an Api client to see if it considers itself compatible, that'd be a nice feature.
git has the ability to fill in keywords when checking out files. Have a look at "Keyword Expansion" on http://progit.org/book/ch7-2.html .
Solutions that require local configuration changes will not work as nobody will use them.
(In reply to comment #6) > git has the ability to fill in keywords when checking out files. Have a look at > "Keyword Expansion" on http://progit.org/book/ch7-2.html . Just because the functionality exists doesn't mean we should use it. There's lots of bad ideas out there ;-) (In reply to comment #7) > Solutions that require local configuration changes will not work as nobody will > use them. This. (In reply to comment #5) > (In reply to comment #2) > > It would be nice to have some kind of versioning on our public API so people > > can detect incompatibilities when they exist. > > Although the previous svn:keywords did not provide that information, that was > just a simple "last rev modified" number. Right now this bug is just to remove > them. We could open a feature enhancement ticket for that other, although I > personally never found that needed and release notes seem to be more useful for > breaking changes. If we create an API module to programmatically be able to > export the version of an Api module, the it could be useful to an Api client to > see if it considers itself compatible, that'd be a nice feature. I'm in favor of simple integer increments. When a module changes in an incompatible way, bump v1 -> v2 (which doesn't happen *often*). But you're right, let's spin that off to another bug and just remove the existing keywords while we bikeshed over that.
Some kind of versioning is definitely required.
Are you going to do something about this?
Gerrit change https://gerrit.wikimedia.org/r/#/c/12155/
(In reply to comment #11) > Gerrit change https://gerrit.wikimedia.org/r/#/c/12155/ There are dozens of core API files that need changing too. Plus all other extensions using this. Like I suggested before, I think we should change this to return an integer, and increment it by 1 anytime a module changes in an incompatible way.
Go ahead Chad. I will be glad to +2 / merges such a change.
*** Bug 38301 has been marked as a duplicate of this bug. ***
Lets start by making the abstract method implemented, so new Api modules people create don't need this method. Just ran into this during a tutorial. "Mr. Krinkle, what's the $Id:$ line for?" :-)
(In reply to comment #15) > Lets start by making the abstract method implemented, so new Api modules people > create don't need this method. Just ran into this during a tutorial. > > "Mr. Krinkle, what's the $Id:$ line for?" :-) Need to make it return something... $wgVersion Oh, and remove "Usually done with SVN's Id keyword" at the same time xD
Now that SVN Id keywords has been removed by I910ca1448ed2ed697ac19b17c486d130aa1d7e03 - should I close this bug too?
I guess :-]
These are still present in many extensions and in http://www.mediawiki.org/wiki/API:Extensions At least the documentation must be updated to reflect the current practice.
Updated docs. The extensions might need to be updated later, as they sometimes get deployed before the new core.
