Release procedure: warn against pushing Replicant versions to branches.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

1 files changed, 28 insertions, 0 deletions

diff --git a/README.txt b/README.txt
index 467007e..73c0906 100644
--- a/README.txt
+++ b/README.txt
@@ -21,6 +21,34 @@ In the vendor/replicant repository:
 In the manifest repository:
 - We need to change all the revisions to use the new tag.
 
+However it's best not to push these vendor/replicant and manifest changes
+yet. Since Replicant 4.2, every repository used to produce the Replicant
+images being released are tagged with the specific version of that release
+(like replicant-6.0-0004-rc2). In addition it's also possible to build the
+latest version of a major Replicant version by using a branch instead
+(like replicant-6.0).
+
+As the branches need to be buildable at any moment, if we push the manifest
+and vendor/replicant modifications described above in the branch of a major
+Replicant version (like replicant-6.0), we will end up with images that will
+indicate that they are coming from a release (like replicant-6.0-0003-rc2)
+instead.
+
+In some cases, this could become a serious issue: If you are using keys that
+have been or will be used in a release, and build an image from a branch,
+if that branch has the Replicant version of a release, people could be
+(accidentally) mislead to think that they are installing a release while they
+are not.
+
+In turn this could lead to a huge number of hours being lost on trying to
+track down regressions due to making the wrong assumption about which image
+is being run.
+
+As we will need to tag all the source code later on, we can just add the
+commits that have the modifications described above in the source code, without
+pushing them: they will then be picked up by the tagging process and be pushed
+in the tag.
+
 Preparing the source code for tagging:
 --------------------------------------
 First you need to make sure that all the commits with the changes mentioned