mirrors/synapse
1
0
Fork 0
mirror of https://github.com/matrix-org/synapse.git synced 2025-10-06 13:01:50 +02:00
Code Issues Projects Releases Wiki Activity

deploy: 7dc14730d925a39a885a14ce309d99054f9617d5

Browse Source
This commit is contained in:
callahad 2021-06-08 10:45:10 +00:00
parent e7a50a0bd0
commit abfede8d5b
4 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
develop/dev/git.html
View File

@ -283,15 +283,15 @@ when a PR is landed, or as part of our release process.</p>
that our active branches are ordered thus, from more-stable to less-stable:</p> that our active branches are ordered thus, from more-stable to less-stable:</p>
<ul> <ul>
<li><code>master</code> (tracks our last release).</li> <li><code>master</code> (tracks our last release).</li>
<li><code>release-vX.Y.Z</code> (the branch where we prepare the next release)<sup <li><code>release-vX.Y</code> (the branch where we prepare the next release)<sup
id="a3"><a href="#f3">3</a></sup>.</li> id="a3"><a href="#f3">3</a></sup>.</li>
<li>PR branches which are targeting the release.</li> <li>PR branches which are targeting the release.</li>
<li><code>develop</code> (our &quot;mainline&quot; branch containing our bleeding-edge).</li> <li><code>develop</code> (our &quot;mainline&quot; branch containing our bleeding-edge).</li>
<li>regular PR branches.</li> <li>regular PR branches.</li>
</ul> </ul>
<p>The corollary is: if you have a bugfix that needs to land in both <p>The corollary is: if you have a bugfix that needs to land in both
<code>release-vX.Y.Z</code> <em>and</em> <code>develop</code>, then you should base your PR on <code>release-vX.Y</code> <em>and</em> <code>develop</code>, then you should base your PR on
<code>release-vX.Y.Z</code>, get it merged there, and then merge from <code>release-vX.Y.Z</code> to <code>release-vX.Y</code>, get it merged there, and then merge from <code>release-vX.Y</code> to
<code>develop</code>. (If a fix lands in <code>develop</code> and we later need it in a <code>develop</code>. (If a fix lands in <code>develop</code> and we later need it in a
release-branch, we can of course cherry-pick it, but landing it in the release release-branch, we can of course cherry-pick it, but landing it in the release
branch first helps reduce the chance of annoying conflicts.)</p> branch first helps reduce the chance of annoying conflicts.)</p>
@ -302,7 +302,7 @@ most intuitive name. <a href="#a1">^</a></p>
<p><b id="f2">[2]</b>: Well, anyone with commit access.<a href="#a2">^</a></p> <p><b id="f2">[2]</b>: Well, anyone with commit access.<a href="#a2">^</a></p>
<p><b id="f3">[3]</b>: Very, very occasionally (I think this has happened once in <p><b id="f3">[3]</b>: Very, very occasionally (I think this has happened once in
the history of Synapse), we've had two releases in flight at once. Obviously, the history of Synapse), we've had two releases in flight at once. Obviously,
<code>release-v1.2.3</code> is more-stable than <code>release-v1.3.0</code>. <a href="#a3">^</a></p> <code>release-v1.2</code> is more-stable than <code>release-v1.3</code>. <a href="#a3">^</a></p>
</main> </main>

8
develop/print.html
View File

@ -11280,15 +11280,15 @@ when a PR is landed, or as part of our release process.</p>
that our active branches are ordered thus, from more-stable to less-stable:</p> that our active branches are ordered thus, from more-stable to less-stable:</p>
<ul> <ul>
<li><code>master</code> (tracks our last release).</li> <li><code>master</code> (tracks our last release).</li>
<li><code>release-vX.Y.Z</code> (the branch where we prepare the next release)<sup <li><code>release-vX.Y</code> (the branch where we prepare the next release)<sup
id="a3"><a href="dev/git.html#f3">3</a></sup>.</li> id="a3"><a href="dev/git.html#f3">3</a></sup>.</li>
<li>PR branches which are targeting the release.</li> <li>PR branches which are targeting the release.</li>
<li><code>develop</code> (our &quot;mainline&quot; branch containing our bleeding-edge).</li> <li><code>develop</code> (our &quot;mainline&quot; branch containing our bleeding-edge).</li>
<li>regular PR branches.</li> <li>regular PR branches.</li>
</ul> </ul>
<p>The corollary is: if you have a bugfix that needs to land in both <p>The corollary is: if you have a bugfix that needs to land in both
<code>release-vX.Y.Z</code> <em>and</em> <code>develop</code>, then you should base your PR on <code>release-vX.Y</code> <em>and</em> <code>develop</code>, then you should base your PR on
<code>release-vX.Y.Z</code>, get it merged there, and then merge from <code>release-vX.Y.Z</code> to <code>release-vX.Y</code>, get it merged there, and then merge from <code>release-vX.Y</code> to
<code>develop</code>. (If a fix lands in <code>develop</code> and we later need it in a <code>develop</code>. (If a fix lands in <code>develop</code> and we later need it in a
release-branch, we can of course cherry-pick it, but landing it in the release release-branch, we can of course cherry-pick it, but landing it in the release
branch first helps reduce the chance of annoying conflicts.)</p> branch first helps reduce the chance of annoying conflicts.)</p>
@ -11299,7 +11299,7 @@ most intuitive name. <a href="dev/git.html#a1">^</a></p>
<p><b id="f2">[2]</b>: Well, anyone with commit access.<a href="dev/git.html#a2">^</a></p> <p><b id="f2">[2]</b>: Well, anyone with commit access.<a href="dev/git.html#a2">^</a></p>
<p><b id="f3">[3]</b>: Very, very occasionally (I think this has happened once in <p><b id="f3">[3]</b>: Very, very occasionally (I think this has happened once in
the history of Synapse), we've had two releases in flight at once. Obviously, the history of Synapse), we've had two releases in flight at once. Obviously,
<code>release-v1.2.3</code> is more-stable than <code>release-v1.3.0</code>. <a href="dev/git.html#a3">^</a></p> <code>release-v1.2</code> is more-stable than <code>release-v1.3</code>. <a href="dev/git.html#a3">^</a></p>
<div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h1 id="opentracing"><a class="header" href="#opentracing">OpenTracing</a></h1> <div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h1 id="opentracing"><a class="header" href="#opentracing">OpenTracing</a></h1>
<h2 id="background"><a class="header" href="#background">Background</a></h2> <h2 id="background"><a class="header" href="#background">Background</a></h2>
<p>OpenTracing is a semi-standard being adopted by a number of distributed <p>OpenTracing is a semi-standard being adopted by a number of distributed

2
develop/searchindex.js
View File

File diff suppressed because one or more lines are too long

2
develop/searchindex.json
View File

File diff suppressed because one or more lines are too long