<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Versioning on Ricky Moorhouse</title>
    <link>https://rickymoorhouse.uk/tags/versioning/</link>
    <description>Recent content in Versioning on Ricky Moorhouse</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <lastBuildDate>Mon, 13 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://rickymoorhouse.uk/tags/versioning/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>API Versioning is a Contract Commitment, not a Technical Choice</title>
      <link>https://rickymoorhouse.uk/blog/2026/api-versioning-is-a-contract-commitment-not-a-technical-choice/</link>
      <pubDate>Mon, 13 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://rickymoorhouse.uk/blog/2026/api-versioning-is-a-contract-commitment-not-a-technical-choice/</guid>
      <description>&lt;p&gt;Teams spend a lot of energy arguing about whether to put the version in the URL, a header, or a query parameter. That debate usually misses the point. The real question is: what is your change management discipline, and how do you protect consumers from breaking changes?&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://rickymoorhouse.uk/blog/2026/api-versioning-is-a-contract-commitment-not-a-technical-choice/windswept.jpeg&#34; alt=&#34;Sand in the wind, Witterings&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;Taking a step up from the versioning question - how are you managing changes to your API contract?  Ideally this would be transparent to consumers unless there is something they are looking to take advantage of in the new changes.  If your API is designed well it can abstract any internal requirements and technical limitations from your clients such that you can update the implementation internally and their applications will continue to operate without even needing to know about it.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
