commit ce0dfd3bb62113357893729a2c93fad0f82467da
from: Thomas Adam <thomas@xteddy.org>
date: Thu Jul 21 13:53:19 2022 UTC

portable: update READMEs with release info

Document how to release a new `-portable` version.

commit - 585fb4308db8e9dd168f98d07dd6a3af76f6a415
commit + ce0dfd3bb62113357893729a2c93fad0f82467da
blob - afa72ab41b82100ff3473ac243f7e200767dd2ca
blob + ae90802d81971ccb442e448a51fe44af0f361a65
--- .github/README.md
+++ .github/README.md
@@ -163,6 +163,49 @@ When updating `-portable` from upstream changes, the f
 
 These steps are encapsulated in a script within `-portable`.  [Link](../maintscripts/sync-upstream.sh)
 
+RELEASING A NEW VERSION
+=======================
+
+Release for `-portable` try and align as close to upstream GoT as much as
+possible, even on the same day where that can happen.  That being said,
+sometimes a release of `-portable` might happen outside of that cadence, where
+a `-portable`-specific issue needs addressing, for example.
+
+Before creating a new release, check the version of GoT as found in
+`configure.ac`:
+
+```
+AC_INIT([got-portable], [0.75], [thomas@xteddy.org])
+
+```
+
+Here, the *to be released* version of `got-portable` will be `0.75`.
+Typically, this version is incremented directly after a release, such that
+there's no need to change this value.  The only exception would be if there
+were an out-of-band release to `-portable`.  In such cases, that would take
+the form:
+
+```
+0.75a
+```
+
+Where the suffix of `a`, `b`, etc., can be used to denote any sub-releases
+from the `0.75` version.
+
+Once the version is verified, the following should be run from the `linux`
+branch -- and the repository should not have any outstanding modifications to
+the source:
+
+```
+make clean ; ./autogen && ./configure && make distcheck
+```
+
+If this succeeds, the tarball is in the CWD, as: `got-portable-VERSION.tar.gz`
+
+This can then be copied to the `got-www` repository and uploaded, along with
+changing a couple of HTML pages therein to represent the new released version.
+Additionally, the CHANGELOG file can be copied to the `got-www` and committed.
+
 TODO
 ====
 
blob - 5e94ff506948ca5730c38c2a95452d9534ed02ef
blob + 63a004434ea67aa086a5ee9fac683b36f54f4144
--- README.portable
+++ README.portable
@@ -166,6 +166,49 @@ When updating `-portable` from upstream changes, the f
 
 These steps are encapsulated in a script within `-portable`.  [Link](../maintscripts/sync-upstream.sh)
 
+RELEASING A NEW VERSION
+=======================
+
+Release for `-portable` try and align as close to upstream GoT as much as
+possible, even on the same day where that can happen.  That being said,
+sometimes a release of `-portable` might happen outside of that cadence, where
+a `-portable`-specific issue needs addressing, for example.
+
+Before creating a new release, check the version of GoT as found in
+`configure.ac`:
+
+```
+AC_INIT([got-portable], [0.75], [thomas@xteddy.org])
+
+```
+
+Here, the *to be released* version of `got-portable` will be `0.75`.
+Typically, this version is incremented directly after a release, such that
+there's no need to change this value.  The only exception would be if there
+were an out-of-band release to `-portable`.  In such cases, that would take
+the form:
+
+```
+0.75a
+```
+
+Where the suffix of `a`, `b`, etc., can be used to denote any sub-releases
+from the `0.75` version.
+
+Once the version is verified, the following should be run from the `linux`
+branch -- and the repository should not have any outstanding modifications to
+the source:
+
+```
+make clean ; ./autogen && ./configure && make distcheck
+```
+
+If this succeeds, the tarball is in the CWD, as: `got-portable-VERSION.tar.gz`
+
+This can then be copied to the `got-www` repository and uploaded, along with
+changing a couple of HTML pages therein to represent the new released version.
+Additionally, the CHANGELOG file can be copied to the `got-www` and committed.
+
 TODO
 ====