[HTTPS-Everywhere] Draft specification for file used to check for ruleset updates

Red redwire at riseup.net
Mon Jun 9 10:26:07 PDT 2014


On 2014-06-09, 2:43 PM, Yan Zhu wrote:
> (adding back HTTPS Everywhere list)
Whoops! I forget that Thunderbird doesn't include the list in the reply
by default! My bad.
> 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
>>> 4.0development.16
>>>
>>> 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.
> https://developer.mozilla.org/en-US/docs/Toolkit_version_format
Oh, I see what you mean.  I interpreted the part that says " A
string-part that exists is always less than a string-part that doesn't
exist" just meant that "pre" and "a" are always less than purely numeric
parts, but I think you're right about that going for any string.

Do you agree with the idea of having the "update" object become an array
of objects with the update's respective information?  It will add some
complexity to the way the update information is parsed (albeit not much)
and probably save a great deal of trouble in configuring preferences
with releases.

>>> 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?)
>> numbers.
>> 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.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140609/ccda79ac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 341 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140609/ccda79ac/attachment.sig>


More information about the HTTPS-Everywhere mailing list