<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 2014-06-09, 2:43 PM, Yan Zhu wrote:<br>
</div>
<blockquote cite="mid:5395EB22.9080308@eff.org" type="cite">
<pre wrap="">(adding back HTTPS Everywhere list)
</pre>
</blockquote>
Whoops! I forget that Thunderbird doesn't include the list in the
reply by default! My bad.<br>
<blockquote cite="mid:5395EB22.9080308@eff.org" type="cite">
<pre wrap="">
On 06/09/2014 10:07 AM, Red wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 2014-06-09, 2:17 PM, Yan Zhu wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
I think "pre" is just an example string; you can actually use whatever
you want and the comparison will still work.
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/Toolkit_version_format">https://developer.mozilla.org/en-US/docs/Toolkit_version_format</a>
</pre>
</blockquote>
Oh, I see what you mean. I interpreted the part that says "
<meta charset="utf-8">
<span style="color: rgb(77, 78, 83); font-family: 'Open Sans',
sans-serif; font-size: 14px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal; line-height:
21px; orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline
!important; float: none; background-color: rgb(255, 255, 255);">A
string-part that exists is always less than a string-part that
doesn't exist" just meant that "pre" and "a" are always less than
purely numeric parts, but I think you're right about that going
for any string.<br>
<br>
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 with releases.<br>
<br>
</span>
<blockquote cite="mid:5395EB22.9080308@eff.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>