<div dir="ltr"><div><br>On 10 June 2014 18:39, Red <<a href="mailto:redwire@riseup.net">redwire@riseup.net</a>> wrote:<br>><br>><br>> On 2014-06-10, 7:05 AM, Maxim Nazarenko wrote:<br>> >I suspect we might use machine-readable date format (like YYYYMMDD) to keep the corresponding code cleaner, since it is mostly internal anyway.<br>

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

<br></div>I see the point and agree it should work well, i18n&l10n issues aside.<br><div><br>><br>> Yan has also stated in her comment (<a href="https://gist.github.com/redwire/2e1d8377ea58e43edb40#comment-1242761">https://gist.github.com/redwire/2e1d8377ea58e43edb40#comment-1242761</a>) 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.<br>

<br></div><div>Both approaches are functionally equivalent, imho, the choice is a matter of convenience.<br><br></div><div>Best regards,<br></div><div>Maxim Nazarenko<br></div></div>