Update instructions to use YYYY.WW.REV for release versions. (#100)

* Update instructions to use YYYY.WW.REV for release versions.
* Add stamp.sh file to more sanely advance the version number.
* Update README and add --release flag

Author: DavidSouther

README.md

@@ -89,27 +89,14 @@ There are two stages, testing and deployment.
 
 1. **Update the -tools version**: Once the tests pass, update the `setup.py` version and create a tag in the -tools repository at the same SHA you identified earlier.
 
-   - Determine the next [semver](https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers) number as appropriate for the changes in this release. e.g. `1.1.4`
-   - Create a local version identifier, with the format `YYYY-MM-DD-A`, where `YYYY-MM-DD` represents release date, and `-A` is used for the first release of the day (followed by `-B`, `-C`, etc., for subsequent same-day releases). e.g. `2024-08-24-A`
+  - Run `stamp.sh` to determine the next version and update `setup.py`. Use `--release` to additionally create a tag and push to main.
+    - Determine the next [stamp](https://blog.aspect.build/versioning-releases-from-a-monorepo) (which is valid [semver](https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers)) number as appropriate for the changes in this release. e.g. `2024.40.2`.
 
-     - Here is a command line script to generate the local identifier, tested on Mac:
-
-     ```
-     TAG_NAME=$(date +%Y-%m-%d)-A && \
-       SHA=$(git rev-parse HEAD) && \
-       git tag -a "$TAG_NAME" "$SHA" -m "Release $TAG_NAME" && \
-       git push origin "$TAG_NAME"
-     ```
-
-   - The new version will be `{NEXT_SEMVER}+{LOCAL_VERSION}`, e.g. `1.1.4+2024-08-24-A`
-     - **Update `setup.py` with this version.**
-   - Create a tag at the SHA from the testing phase, using the local version identifier.
-
-2. **Update your testing PR branch**: Remove SHA and add tag to [validate-doc-metadata.yml](https://github.com/awsdocs/aws-doc-sdk-examples/blob/main/.github/workflows/validate-doc-metadata.yml)
+1. **Update your testing PR branch**: Remove SHA and add tag to [validate-doc-metadata.yml](https://github.com/awsdocs/aws-doc-sdk-examples/blob/main/.github/workflows/validate-doc-metadata.yml)
    - NOTE: Remove the SHA from [.doc_gen/validation.yaml](https://github.com/awsdocs/aws-doc-sdk-examples/blob/main/.doc_gen/validation.yaml)
-   - This is easily accomplished in the UI.
-3. **Create a release**: Use the automated ["Create release from tag" button](https://github.com/awsdocs/aws-doc-sdk-examples-tools/releases/new) to create a new release with the new tag.
-4. **Perform internal update process**.
+   - This is easily accomplished in the Github UI.
+2. **Create a release**: Use the automated ["Create release from tag" button](https://github.com/awsdocs/aws-doc-sdk-examples-tools/releases/new) to create a new release with the new tag.
+3. **Perform internal update process**.
 
 ## Security
 

setup.py

@@ -5,7 +5,7 @@
 
 setup(
     name="aws_doc_sdk_examples_tools",
-    version="1.0.4+2024-09-20-A",
+    version="2024.40.0",
     packages=["aws_doc_sdk_examples_tools"],
     package_data={"aws_doc_sdk_examples_tools": ["config/*.yaml"]},
     entry_points={

stamp.sh

@@ -0,0 +1,62 @@
+#!/bin/sh
+
+set -e # Exit on errors
+# set -x # Shell debugging
+
+# First, check that we're on the main branch.
+BRANCH=$(git rev-parse --abbrev-rev HEAD)
+if [ "$BRANCH" != "main" ] ; then 
+    echo "Not on main, exiting!" 
+    exit 1
+fi 
+
+# And check that the main branch is clean
+STATUS=$(git status --porcelain)
+if [ -n "${STATUS}" ] ; then
+    echo "Repository is not clean, exiting!" 
+    exit 1
+fi 
+
+# And check that the REMOTE points to the -tools repo.
+REMOTE="${REMOTE:-origin}"
+if [[ "$(git remote get-url $REMOTE 2>/dev/null)" != *"awsdocs/aws-doc-sdk-examples-tools.git"* ]] ; then
+    echo "REMOTE=${REMOTE} is not set to awsdocs/aws-doc-sdk-examples-tools.git, please adjust accordingly and rerun."
+    exit 1
+fi
+
+# CURRENT and NEXT have the format YYYY.WW.REV, where YYYY is the current year,
+# WW is the current week, and REV is the number of releases this week.
+# The next revision compares the two, in this way
+# - If NEXT is later than CURRENT in any fields, accept NEXT.
+# - Otherwise, return CURRENT, with one added to REV.
+#
+# THIS FUNCTION IS NOT TRANSITIVE! It must be called with
+# `compare_versions CURRENT NEXT`
+compare_versions() {
+    if [[ "$1" < "$2" ]] ; then
+        echo "$2"
+    else
+        IFS='.' read -r y1 w1 r1 <<< "$1"
+        r1=$((r1 + 1))
+        echo "${y1}.${w1}.${r1}"
+    fi
+}
+
+# compare_versions 2024.44.4 2024.44.0 # 2024.44.5
+# compare_versions 2024.44.4 2024.45.0 # 2024.45.0
+# compare_versions 2024.44.4 2025.1.0 # 2025.1.0
+
+CURRENT=$(grep version= setup.py | awk -F\" '{print $2}')
+NEXT=$(date +%Y.%W.0)
+VERSION=$(compare_versions "$CURRENT" "$NEXT")
+echo "Releasing $VERSION..."
+sed "/version=/ s/$CURRENT/$VERSION/" setup.py > setup.py.out ; mv setup.py.out setup.py
+git --no-pager diff
+git add setup.py
+git commit --message "Release ${VERSION}"
+
+if [ "$1" == "--release" ] ; then
+    git tag "$VERSION" main
+    git push "$REMOTE" "$VERSION"
+    git push "$REMOTE" main
+fi