commit ce0dfd3bb62113357893729a2c93fad0f82467da from: Thomas Adam 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 ====