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

[Yan Zhu]

(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
>> 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

>> 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.
> 


-- 
Yan Zhu  <yan at eff.org>, <yan at torproject.org>
Staff Technologist
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...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140609/a712c08c/attachment-0001.sig>