<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>smsm42</author><text>&amp;gt; just use the commit hash&lt;p&gt;Does the author honestly fail to realize that commit hashes are incomprehensible to most humans and look like noise, it takes extraordinary mental effort to compare them? While difference between 1.2.3 and 1.4.5 is instantly apparent to any human?&lt;p&gt;&amp;gt; Pinning is absolutely crucial when building software from some sources out of your control&lt;p&gt;Amen. I am surprised how the author does not recognize it.&lt;p&gt;In fact, the only idea that does not come as outright false immediately after reading is &amp;quot;if you change behavior, rename&amp;quot;. But thinking about it for a bit, it is wrong too. First, naming is hard. Finding good recognizable name for a package is hard enough, if each BC break would require a new one, we&amp;#x27;d drown in names. Second, behavior breaks are not total. If RoR or ElasticSearch releases a new version with BC break, they do not stop being essentially the same package just with somewhat different behavior. Most of the knowledge you had about it is still relevant. Some pieces are broken, but not the whole concept. New name requires throwing out the whole concept and building a new one, essentially. It is not good for incremental gradual change.</text><parent_chain><item><author>jitl</author><text>Here’s the post’s core thesis:&lt;p&gt;&amp;gt; At this point you could even get rid of the version altogether and just use the commit hash on the rare occasions when we need a version identifier. We&amp;#x27;re all on the internet, and we&amp;#x27;re all constantly running npm install or equivalent. Just say &amp;quot;Leftpad-17&amp;quot;, it&amp;#x27;s cleaner.&lt;p&gt;&amp;gt; And that&amp;#x27;s it. Package managers should provide no options for version pinning.&lt;p&gt;&amp;gt; A package manager that followed such a proposal would foster an eco-system with greater care for introducing incompatibility. Packages that wantonly broke their consumers would &amp;quot;gain a reputation&amp;quot; and get out-competed by packages that didn&amp;#x27;t, rather than gaining a &amp;quot;temporary&amp;quot; pinning that serves only to perpetuate them.&lt;p&gt;Pinning is absolutely crucial when building software from some sources out of your control, especially with larger teams or larger software. You &lt;i&gt;cannot rely&lt;/i&gt; on the responsibility of others, be they 100s of upstream library authors, or 100s of other peer developers on your product. One among those people may cause a dependency to break your build, either by releasing a bad version, or foolishly adding a dependency without carefully checking its “reputation” for frequent breaking changes.&lt;p&gt;In either case, &lt;i&gt;without pinning, your build is non-deterministic&lt;/i&gt; and sometimes starts failing it’s tests without any diff. You can’t bisect that. Your only remediation is manual debugging and analysis. Work stops for N engineers because everyone’s branches are broken.&lt;p&gt;I don’t think any level of community fostering is worth that kind of risk.</text></item></parent_chain></comment><story><title>The cargo cult of versioning</title><url>http://akkartik.name/post/versioning</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>masklinn</author><text>&amp;gt; Pinning is absolutely crucial when building software from some sources out of your control, especially with larger teams or larger software. You cannot rely on the responsibility of others, be they 100s of upstream library authors, or 100s of other peer developers on your product.&lt;p&gt;In fact &lt;i&gt;that&amp;#x27;s the entire reason why &amp;quot;semantics versioning&amp;quot; doesn&amp;#x27;t really work&lt;/i&gt;:&lt;p&gt;* you can never be certain that the maintainer actually follows it&lt;p&gt;* one user&amp;#x27;s breaking change is one maintainer&amp;#x27;s bugfix&lt;p&gt;* while some packaging systems attempt to automate and enforce it (e.g. Elm&amp;#x27;s) even that only goes so far due to type system limitations (e.g. changing acceptable values from [0, 4] to [0, 4[ as a side-effect of some change deep in the bowels of the library&amp;#x27;s logic is pretty much guaranteed &lt;i&gt;not&lt;/i&gt; to surface if you don&amp;#x27;t have a dependent type system, and may not do so even then)</text><parent_chain><item><author>jitl</author><text>Here’s the post’s core thesis:&lt;p&gt;&amp;gt; At this point you could even get rid of the version altogether and just use the commit hash on the rare occasions when we need a version identifier. We&amp;#x27;re all on the internet, and we&amp;#x27;re all constantly running npm install or equivalent. Just say &amp;quot;Leftpad-17&amp;quot;, it&amp;#x27;s cleaner.&lt;p&gt;&amp;gt; And that&amp;#x27;s it. Package managers should provide no options for version pinning.&lt;p&gt;&amp;gt; A package manager that followed such a proposal would foster an eco-system with greater care for introducing incompatibility. Packages that wantonly broke their consumers would &amp;quot;gain a reputation&amp;quot; and get out-competed by packages that didn&amp;#x27;t, rather than gaining a &amp;quot;temporary&amp;quot; pinning that serves only to perpetuate them.&lt;p&gt;Pinning is absolutely crucial when building software from some sources out of your control, especially with larger teams or larger software. You &lt;i&gt;cannot rely&lt;/i&gt; on the responsibility of others, be they 100s of upstream library authors, or 100s of other peer developers on your product. One among those people may cause a dependency to break your build, either by releasing a bad version, or foolishly adding a dependency without carefully checking its “reputation” for frequent breaking changes.&lt;p&gt;In either case, &lt;i&gt;without pinning, your build is non-deterministic&lt;/i&gt; and sometimes starts failing it’s tests without any diff. You can’t bisect that. Your only remediation is manual debugging and analysis. Work stops for N engineers because everyone’s branches are broken.&lt;p&gt;I don’t think any level of community fostering is worth that kind of risk.</text></item></parent_chain></comment><story><title>The cargo cult of versioning</title><url>http://akkartik.name/post/versioning</url></story>