[HTTPS-Everywhere] Draft specification for file used to check for ruleset updates
yan at eff.org
Mon Jun 9 10:13:06 PDT 2014
(adding back HTTPS Everywhere list)
On 06/09/2014 10:07 AM, Red wrote:
> On 2014-06-09, 2:17 PM, Yan Zhu wrote:
>> Wouldn't this also be solved by making the ruleset versions sub-versions
>> of the releases?
>> ex: 4.0development.16.0 == first ruleset release corresponding to
>> It would be better to stick to the existing convention for naming
>> branches and not introduce "pre" (we actually use "pre" to denote a
>> build that is not intended for release).
> The reason I think we would have to go with the "pre" convention is
> because that seems to be what the nsIVersionComparator interface you
> suggested we use relies on. This approach would really restrict our
> choices for naming conventions.
I think "pre" is just an example string; you can actually use whatever
you want and the comparison will still work.
>> I don't see any downsides to having two different update.json files at
>> two separate URLs for stable vs. development. If these are specified as
>> prefs in the extension, it's possible for superusers to manually change
>> them if they want the ruleset library for the other branch. I doubt many
>> people will want to, though.
> I actually really like the solution Maxim put forth of serving one
> update.json file with an array of update fields, with each object in the
> array containing update information for different branches. The user
> could still have the freedom to change their extension's preference from
> stable to development and back, changing the behavior of the updater as
> such. This approach wouldn't restrict the way we version things as long
> as we have a way to compare version (nsIVersionComparator exclusively?)
> We'd be serving the zipped database files from different URLS, but since
> those URLs can be specified when the update.json file is created, beyond
> adding a release-type preference (stable, developmental, etc.), no extra
> preference tweaking would have to be done every time a release of the
> extension (particularly, ones where the stable version number takes on
> the previous developmental version number base, i.e. version 4.0 becomes
> stable) is put out.
Yan Zhu <yan at eff.org>, <yan at torproject.org>
Electronic Frontier Foundation https://www.eff.org
815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: OpenPGP digital signature
More information about the HTTPS-Everywhere