On 2014-06-10, 7:16 AM, Maxim Nazarenko wrote: > On 9 June 2014 20:57, Yan Zhu <[email protected] <mailto:[email protected]>> wrote: > > > > On 06/09/2014 09:50 AM, Seth David Schoen wrote: > > > Does that mean that you can't update to a new ruleset release without > > > first updating to the corresponding extension release version? > > > > > > > We decided in IRC last week that this would be the desired default > behavior. > > > > In general, it would be difficult to guarantee that a new ruleset > > version is compatible with *all* previous extension versions. Ex: we > > introduce a new XML property, "hasKeyPins", or change the XML ruleset > > structure in a way that is not backwards-compatible past the previous > > extension release. > Second that. In fact, the ruleset needn't be forward compatible, i.e > the current extension doesn't need to understand old ruleset formats. > > I strongly suggest having db_version field (which is bumped every time > the ruleset _format_ is changed) for this purpose. 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.
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. > Best regards, > Maxim Nazarenko > > > _______________________________________________ > HTTPS-Everywhere mailing list > [email protected] > https://lists.eff.org/mailman/listinfo/https-everywhere
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
