<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>With the way TB's releases currently work, I think to pull that off, each time you create a new ESR you'd have to rename the existing mozilla-release repository to mozilla-esrXX and then create a new mozilla-release repository, and then mozilla-release would be the current ESR until it's no longer current.<br></div><div><br></div><div>On Mon, Nov 9, 2020, at 2:39 PM, Ben Bucksch wrote:<br></div><blockquote type="cite" id="qt" style=""><div class="qt-moz-cite-prefix">Hi Rob,<br></div><div class="qt-moz-cite-prefix"><br></div><div class="qt-moz-cite-prefix">I think this should also go to maildev.
Adding CC.<br></div><div class="qt-moz-cite-prefix"><br></div><div class="qt-moz-cite-prefix">So, a question: If we wanted to build
test the current released code (or about-to-be released code), or
if we wanted to backport patches that do not apply cleanly and
create a clean branch patch, which repo URL would we use?<br></div><div class="qt-moz-cite-prefix"><br></div><div class="qt-moz-cite-prefix">In order to script things, it would be
preferably to have a single URL that always gives the current
release, instead of having to change from comm-esr60 to comm-esr68
to comm-esr78 to... yes, which one is the next? I don't know when
to pull which URL. Also, it's easier for documentation when the
URL is always the same, and stays identical for years.<br></div><div class="qt-moz-cite-prefix"><br></div><div class="qt-moz-cite-prefix">Ben<br></div><div class="qt-moz-cite-prefix"><br></div><div class="qt-moz-cite-prefix"><br></div><div class="qt-moz-cite-prefix">Am 09.11.20 um 19:53 schrieb Rob
Lemley:<br></div><blockquote type="cite" cite="mid:b870331c-5317-a3f7-3be3-f007a381280f@thunderbird.net"><div><br></div><div>Starting with next week's merges, I do not plan on updating the <b>comm-release</b> repository and intend to have it set to a read-only state.<br></div><div> <br></div><div> Thunderbird has not used comm-release in several years (except in
creation of new ESR repositories). I reviewed the push log going
back to pre-Thunderbird 60. There was one push that was not part
of merge day activities. The Seamonkey team has indicated that
this change is okay with them.<br></div><div> <br></div><div> With regard to the next ESR repository, it can be created from
comm-beta. There is no reason for the extra step.<br></div><div> <br></div><div> Additionally, there is the never-used <span class="qt-list"><b>comm-moz-esr68</b></span> repository that I will ask to be removed.<br></div><div> <br></div><div> -Rob<br></div><div> <br></div><div> <br></div><div class="qt-moz-signature"><div>--<br></div><div> <br></div><div><div><br></div><div><div><span class="font" style="font-family:menlo, consolas, "courier new", monospace;"><b>Rob Lemley</b><br> Thunderbird Release Engineer<br> <a class="qt-moz-txt-link-abbreviated" href="mailto:rob@thunderbird.net">rob@thunderbird.net</a> - :rjl<br> -*- #thereisonlyxul -*-</span></div></div></div></div><div><br></div><pre class="qt-moz-quote-pre">_______________________________________________
tb-planning mailing list
<a class="qt-moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="qt-moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
<br></pre></blockquote><p><br></p><div>_______________________________________________<br></div><div>tb-planning mailing list<br></div><div><a href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a><br></div><div><a href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a><br></div><div><br></div></blockquote><div><br></div></body></html>