> > > 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. > > version here is not for notification, its for the client to specify what it expects the behavior to be. Fixing bugs does not change version, not unless there is a *breaking* change - if we decide to obsolete ver5 and start ver6 due to inability to include new features. This is a very rare occurrence. APIv1 lasted for 6 years and still going strong :)
> > Mark Nottingham recently wrote about semver, REST and how to evolve > Web APIs [1]. I think developers are increasingly familiar with > interacting with REST style APIs (Amazon S3, Twitter, Facebook, etc). > In general REST APIs encourage simpler documentation, easier > cacheability, and can often make the need for 3rd party API libraries > disappear, if a good HTTP library is available. > > A change to the major version of the Mediawiki API might be a good > time to think make a fresh start and think about the API in this > way...or not :-) > > Make a proposal, we discuss, and than we start throwing rotten tomatoes in a different direction ;)
_______________________________________________ Mediawiki-api mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
