Yan and Jacob and I have been talking about version number strings in the update manifest that we've been refining a little bit lately. I wrote in my comment on the gist (https://gist.github.com/redwire/2e1d8377ea58e43edb40) that I was thinking that we could have a part of the version string be interpreted specially as meaning the ruleset release is for the development release of the extension vs the stable version. While it would technically be possible to, for example say that a ruleset release versioned A.B.C.preD could be interpreted as being version A.B.C.D of the ruleset library for the developmental release of the extension (pre, in this case, denoting this), this still leaves us with the problem of serving different releases.
The extension will have to be able to fetch the most recent ruleset
release information (the appropriate update.json file) for any given
version of the extension- developmental or otherwise. If we were to
adopt an approach of marking the ruleset version like I described above
to distinguish between developmental and stable releases, we would be
able to serve one update.json file from one specific URL at all times.
This, however, leads to the problem that many clients could fail to
update between stable and developmental ruleset releases. The only
reasonable thing to do about this is to make the extension aware of
specifically which URL it is to fetch an appropriate update.json file
from. That is, a stable HTTPS-E release may fetch the file from
eff.org/.../update-stable.json, and a developmental release of the
extension may fetch from eff.org/.../update-devel.json.
To make it possible for the extension to make this distinction without
requiring more extra work from the project's maintainers (such as in the
case of remembering to update the format_version preference for database
file compatibility we discussed), I propose the following solution:
Releases of the extension store version information (in a preference,
perhaps) (is this already done somehow?) pertaining to whether the
release is a dev. release or a stable release.
The extension refers to a hard-coded mapping (JS Object) of version type
to the URL to fetch the appropriate JSON file from.
I realize I'm back to proposing something we decided would be best
avoided in the case of the database version format preference, which
would require extra attention from maintainers and developers. However,
I think that this, unlike the database format version preference idea,
is far more reasonable, as the only change that would have to be made
would be to a string constant or preference that we might expect would
only take on one of two or three easily-understood and descriptive
values ('developmental', 'stable', 'willeatyourcomputer', ...).
I'd like to know if anyone has a simpler idea for making the distinction
between version types than this!
Cheers,
Zack
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
