<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:media="http://search.yahoo.com/mrss/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sam Wilson's Website :: versioning</title><link>https://twyne.samwilson.id.au/T2090</link><atom:link href="https://twyne.samwilson.id.au/T2090/rss.xml" rel="self" type="application/rss+xml"/><lastBuildDate>Fri, 07 Aug 2026 22:27:28 +0000</lastBuildDate><item><title>Where to store the version number</title><description>&lt;p&gt;It’s Wednesday morning, coffee is made, and &lt;a href="https://svgtranslate.toolforge.org/"&gt;SVG Translate&lt;/a&gt; is being upgraded to 2.0.0. I think that bumping major version numbers for underlying platform upgrades is slightly controversial, but I do it. My reasoning is that a major version primarily indicates that “something” must be done when you upgrade, and that’s definitely true when dropping support for old versions of PHP.&lt;/p&gt;
&lt;p&gt;A few of the tools that use the &lt;a href="https://github.com/wikimedia/ToolforgeBundle"&gt;ToolforgeBundle&lt;/a&gt; for Symfony display their current version number in the footer, and they do so by running &lt;code&gt;git describe&lt;/code&gt; to get the current tag. This is proving to be silly when the filesystem is slow, and is timing out. It’d be better to have the current version number within the codebase somewhere — the trouble with that is remembering to keep it in sync. Ideally, I think, it’d be in a &lt;code&gt;VERSION&lt;/code&gt; file, and would get updated every time a change is made so that there’s only ever one commit with a given version (other than &lt;code&gt;-dev&lt;/code&gt; ones; i.e. the next commit after a release would add that).&lt;/p&gt;</description><link>https://twyne.samwilson.id.au/P26707</link><guid isPermaLink="true">https://twyne.samwilson.id.au/P26707</guid><pubDate>Wed, 06 Mar 2024 01:37:00 +0000</pubDate></item></channel></rss>
