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

[Maxim Nazarenko]

On 10 June 2014 18:39, Red <redwire at riseup.net> wrote:
>
>
> On 2014-06-10, 7:05 AM, Maxim Nazarenko wrote:
> >I suspect we might use machine-readable date format (like YYYYMMDD) to
keep the corresponding code cleaner, since it is mostly internal anyway.
>
> Yan has been talking about using subversions of the extension release
version for the ruleset releases.  That way we can easily compare version
types using the nsIVersionComparator XPCOM class and have the heavy lifting
done for us.  We'll leave a date field in the update object, but it would
just be something there to present to users so they can be informed when
their most recent ruleset update was.

I see the point and agree it should work well, i18n&l10n issues aside.

>
> Yan has also stated in her comment (
https://gist.github.com/redwire/2e1d8377ea58e43edb40#comment-1242761) that
she feels it might still be better to take the approach of releasing
several different update.json files corresponding to different extension
release types.

Both approaches are functionally equivalent, imho, the choice is a matter
of convenience.

Best regards,
Maxim Nazarenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140611/38cdf0b8/attachment.html>