<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 2014-06-10, 7:16 AM, Maxim Nazarenko wrote:<br>
<blockquote
cite="mid:CAKGkX-33uSthU46d-9WHSjNa7=8=4ritTmkf4O4jqPpS=LMv2w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>On 9 June 2014 20:57, Yan Zhu <<a moz-do-not-send="true"
href="mailto:yan@eff.org">yan@eff.org</a>> wrote:<br>
><br>
> On 06/09/2014 09:50 AM, Seth David Schoen wrote:<br>
> > Does that mean that you can't update to a new
ruleset release without<br>
> > first updating to the corresponding extension
release version?<br>
> ><br>
><br>
> We decided in IRC last week that this would be the
desired default behavior.<br>
><br>
> In general, it would be difficult to guarantee that a new
ruleset<br>
> version is compatible with *all* previous extension
versions. Ex: we<br>
> introduce a new XML property, "hasKeyPins", or change the
XML ruleset<br>
> structure in a way that is not backwards-compatible past
the previous<br>
> extension release.<br>
</div>
Second that. In fact, the ruleset needn't be forward compatible,
i.e the current extension doesn't need to understand old ruleset
formats.<br>
<div><br>
I strongly suggest having db_version field (which is bumped
every time the ruleset _format_ is changed) for this purpose.<br>
</div>
</div>
</blockquote>
The subject of the db_version field was discussed at length in last
week's IRC meeting. The conclusion of the conversation was that it
would be too much to expect developers to remember to bump the value
of the preference in the extension every time such a change is
made. My understanding is that dealing with incompatibilities going
forward will handled more or less automatically by the fact that the
extension would reject ruleset releases corresponding to a newer
version of the extension.<br>
<br>
So if HTTPS-E were modified in such a way that the ruleset database
format were to change, the extension itself would be receiving a
version upgrade (perhaps going from 3.5.1 to 3.5.2), in which case a
client still running 3.5.1 would not download a ruleset update with
version 3.5.2.X assuming they are on 3.5.1.Y. When this scenario is
encountered by a client, we could even present the user with a
message encouraging them to upgrade the extension, keeping everyone
up to date.<br>
<blockquote
cite="mid:CAKGkX-33uSthU46d-9WHSjNa7=8=4ritTmkf4O4jqPpS=LMv2w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Best regards,<br>
</div>
<div>Maxim Nazarenko<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
HTTPS-Everywhere mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HTTPS-Everywhere@lists.eff.org">HTTPS-Everywhere@lists.eff.org</a>
<a class="moz-txt-link-freetext" href="https://lists.eff.org/mailman/listinfo/https-everywhere">https://lists.eff.org/mailman/listinfo/https-everywhere</a></pre>
</blockquote>
<br>
</body>
</html>