summary refs log tree commit diff
path: root/develop/print.html
diff options
context:
space:
mode:
authorcallahad <callahad@users.noreply.github.com>2021-06-08 10:45:10 +0000
committercallahad <callahad@users.noreply.github.com>2021-06-08 10:45:10 +0000
commitabfede8d5be9db98165ff20ed503f81be01db78e (patch)
treef09b5cf83c0bc361ea2eefde005c15ef8e83ac05 /develop/print.html
parentdeploy: beb251e3eed3f5b93fafea4650ba7146bb19bcf9 (diff)
downloadsynapse-abfede8d5be9db98165ff20ed503f81be01db78e.tar.xz
deploy: 7dc14730d925a39a885a14ce309d99054f9617d5
Diffstat (limited to 'develop/print.html')
-rw-r--r--develop/print.html8
1 files changed, 4 insertions, 4 deletions
diff --git a/develop/print.html b/develop/print.html

index ec92c0dca4..1a4df2fc5c 100644 --- a/develop/print.html +++ b/develop/print.html
@@ -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> <ul> <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> <li>PR branches which are targeting the release.</li> <li><code>develop</code> (our &quot;mainline&quot; branch containing our bleeding-edge).</li> <li>regular PR branches.</li> </ul> <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.Z</code>, get it merged there, and then merge from <code>release-vX.Y.Z</code> to +<code>release-vX.Y</code> <em>and</em> <code>develop</code>, then you should base your PR on +<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 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> @@ -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="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, -<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> <h2 id="background"><a class="header" href="#background">Background</a></h2> <p>OpenTracing is a semi-standard being adopted by a number of distributed