<div>Requiring a new version to support new features and having existing code be compatible with a new version are two different things. <br></div><div><br></div><div><div class="gmail_quote"><div>On Wed, Jun 14, 2017 at 12:44 Rien &lt;<a href="mailto:Rien@balancingrock.nl" target="_blank">Rien@balancingrock.nl</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On 14 Jun 2017, at 13:29, Tanner Nelson &lt;tanner@vapor.codes&gt; wrote:<br>
&gt;<br>
&gt; Unless there is a need to be able to exhaustively switch over all supported HTTP versions, using an enum seems overly restrictive. Especially when considering that adding or removing cases from enums is a breaking change (requires a major version bump).<br>
<br>
I presume that supporting a new HTTP version will always require a major version bump.<br>
<br>
Rien.<br>
<br>
<br>
&gt; As authors of a general purpose HTTP package, we should be avoiding unnecessary restrictions wherever possible.<br>
&gt;<br>
&gt; As an aside, Go also uses two integers to represent major and minor. <a href="https://golang.org/pkg/net/http/#Request" rel="noreferrer" target="_blank">https://golang.org/pkg/net/http/#Request</a><br>
&gt; On Wed, Jun 14, 2017 at 11:38 Rien via swift-server-dev &lt;<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On 14 Jun 2017, at 12:11, Helge Heß via swift-server-dev &lt;<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; On 14. Jun 2017, at 11:36, Rien via swift-server-dev &lt;<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt; On 14 Jun 2017, at 11:14, Chris Bailey &lt;<a href="mailto:BAILEYC@uk.ibm.com" target="_blank">BAILEYC@uk.ibm.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; One factor is whether you consider the version to be discrete values or a structured format for data - I&#39;d argue that we have a structured format due to the expectation that future versions of the HTTP spec could arrive.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; But do you want your code littered with numerical tests or conceptual tests?<br>
&gt; &gt;&gt; Suppose a new version of HTTP does arrive, do you really want to manually walk through the code and find all tests on the numerical values?<br>
&gt; &gt;&gt; Or would it be easier to use switch statements on an enum and have all missing cases pointed out to you?<br>
&gt; &gt;<br>
&gt; &gt; This is actually a argument *for* using numbers. When using an enum in an API makes the same break every time you change it. And that is killer for a an API representing a living protocol like HTTP.<br>
&gt; &gt;<br>
&gt; &gt; Also in proper source you would check for: `if major &gt;= 2`, not `==`, another advantage of using version _numbers_.<br>
&gt; &gt;<br>
&gt; &gt; In the context of HTTPVersion<br>
&gt;<br>
&gt; Precisely. I am making the argument for enum’s only for the HTTPVersion since it is such a unique feature.<br>
&gt;<br>
&gt;<br>
&gt; &gt; I think there shouldn’t be too much discussion though, for two reasons:<br>
&gt; &gt; - If we get HTTP/3.x, we almost certainly have a new API revision.<br>
&gt;<br>
&gt; Absolutely.<br>
&gt;<br>
&gt; &gt; - The HTTP version should only matter for logging purposes. The differences in capabilities<br>
&gt; &gt;  should be handled by the implementation (e.g. keep alive vs not, multiplexing or not, etc).<br>
&gt;<br>
&gt; Agreed, which is why the decision should be made carefully. An API developer usually sees things differently from an API user. Conceptually a version number is just a tag. It does not represent a numerical value. Which makes testing for numerical values error prone, which leads to your following point:<br>
&gt;<br>
&gt; &gt;  In other words, you should never have to check for the versions, but rather features.<br>
&gt;<br>
&gt; Again, fully agreed. But which I interpret as an argument in favour of enums...<br>
&gt;<br>
&gt; Rien.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; hh<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; swift-server-dev mailing list<br>
&gt; &gt; <a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br>
&gt; &gt; <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-server-dev mailing list<br>
&gt; <a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br>
<br>
</blockquote></div></div>