Thanks Yuri.
I'll give further feedback on the talk page.
On Tue, Jan 8, 2013 at 10:19 AM, Yuri Astrakhan wrote:
> Federico, I have added some PHP samples, is this what you were looking for?
>
> Also, added to the page - query~2 submodule (list, prop, meta) versioning
> and behavior.
>
> https:
Federico, I have added some PHP samples, is this what you were looking for?
Also, added to the page - query~2 submodule (list, prop, meta) versioning
and behavior.
https://www.mediawiki.org/wiki/Requests_for_comment/API_Future
P.S. This is wiki, feel free to comment and/or change the proposal.
I think we should discuss it on the talk page, as liquid threads are on and
running nicely. If someone has a sub-proposal, it should be added as a
section to the main page with examples, or if its big, as a subpage. When
we have the points of contention, we could have a yei/nei voting underneath
ea
I went through the proposal and despite I technically understand how that
would look like, I'd suggest to add a section with a real example of how
the PHP code of one module supporting 2/3 versions of the same action would
look like.
It would help assessing the maintainability of the proposed mode
On Mon, Jan 7, 2013 at 9:20 AM, Yuri Astrakhan wrote:
> Following some good feedback, I have created an RFC page detailing many
> changes to the new API.
>
> Please add your suggestions and requests there.
>
> http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
That page doesn't seem to
Following some good feedback, I have created an RFC page detailing many
changes to the new API.
Please add your suggestions and requests there.
http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
___
Mediawiki-api mailing list
Mediawiki-api@li
>
>
> Ok, so you are seeing every increment as a major version change then.
> I think semver helps to be explicit about what the version number
> actually means. I guess in part I'm trying to understand why fixing
> bugs involves a major version change, and breaking backwards
> compatibility.
>
> v
On Fri, Dec 28, 2012 at 6:28 AM, Yuri Astrakhan wrote:
> I'm not sure how semver applies here really - every number change (1->2) is
> a breaking change, and v2 could be marked as experimental in the docs until
> it is ready.
Ok, so you are seeing every increment as a major version change then.
I
I'm not sure how semver applies here really - every number change (1->2) is
a breaking change, and v2 could be marked as experimental in the docs until
it is ready.
Not sure about restful yet - it might not provide much benefit to the
users. I guess we should have either a different thread or bug
Thanks for the additional details :-)
Perhaps this isn't important right now, but have you given any thought
to the naming of the version? I kind of like the clarity and goals of
the semver system [1]. The reason why I bring this up is that fixing
existing bugs with the API sounds like minor chang
Bugzilla, mailing list archives, our heads. Now that versionning is
per-module, we can start revising them one at a time to support new
capabilities. Bugzilla has 150+ open API bugs.
There is an API v2 tracking bug at
https://bugzilla.wikimedia.org/show_bug.cgi?id=38891
Make sure bug 38891 depends
On Fri, Dec 28, 2012 at 5:45 AM, Yuri Astrakhan wrote:
> Let the rotten egg throwing commence!
Sorry to be dense, but where is a good place to learn about what
changes are in being planned for v2 of the API?
//Ed
___
Mediawiki-api mailing list
Mediawi
It's almost New Year, and time for presents (according to the Russian
traditions).
I hereby present you the API versioning framework. Navigate to
https://gerrit.wikimedia.org/r/#/c/41014/ and get that patch to your local
installation for a test run.
There shouldn't be any visible functionality ch
13 matches
Mail list logo
