(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 <[email protected]>, <[email protected]> Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
