On 9 June 2014 20:57, Yan Zhu wrote:
>
> On 06/09/2014 09:50 AM, Seth David Schoen wrote:
> > Does that mean that you can't update to a new ruleset release without
> > first updating to the corresponding extension release version?
> >
>
> We decided in IRC last week that this would be the desired
On 2014-06-10, 7:05 AM, Maxim Nazarenko wrote:
> Good morning!
>
> I suspect we might use machine-readable date format (like MMDD) 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
On 2014-06-10, 7:16 AM, Maxim Nazarenko wrote:
> On 9 June 2014 20:57, Yan Zhu mailto:[email protected]>> wrote:
> >
> > On 06/09/2014 09:50 AM, Seth David Schoen wrote:
> > > Does that mean that you can't update to a new ruleset release without
> > > first updating to the corresponding extension releas
On 06/09/2014 10:26 AM, Red wrote:
> 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 trou
>> 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
On 06/10/2014 12:21 PM, Red wrote:
>
>>> 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 de
>
> Taking the signature into account, the schema that makes the most sense
> to me is:
>
> { "update": { "stable": {...}, "development": {...} }
> "signature": ... }
>
> where "signature" is over the stringified value of "update".
>
I wound up needing to address this same problem for the STARTT
On 2014-06-10, 5:04 PM, Yan Zhu wrote:
> On 06/10/2014 12:21 PM, Red wrote:
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
>
> How about just sticking to the format we have now for update.json and
> going with the decision to serve multiple versions from different URLs
> depending on the release type?
>
This sounds good to me. Yan, sound good to you?
___
HTTPS-Everywhere mai
On 06/10/2014 01:40 PM, Jacob Hoffman-Andrews wrote:
> How about just sticking to the format we have now for update.json and
> going with the decision to serve multiple versions from different URLs
> depending on the release type?
>
>
> This sounds good to me. Yan, sound good to you?
The specific format is not a requirement, just that it be external to the
JSON. Something friendlier to extensions would be fine too.
On Jun 10, 2014 1:57 PM, "Yan Zhu" wrote:
> On 06/10/2014 01:40 PM, Jacob Hoffman-Andrews wrote:
> > How about just sticking to the format we have now for upda
11 matches
Mail list logo
