Implement automated version incrementing and Git tagging on deployments

[Copilot]

Description

Implements automated version tracking for production deployments. Every push to main now increments the version number, commits it back, creates a Git tag, and deploys to GitHub Pages.

Changes

GitHub Actions Workflow (.github/workflows/deploy.yml)

• Version Management: Reads _includes/VERSION.txt, increments integer value, writes back
• Git Operations: Auto-commits VERSION.txt with chore: bump version to XXXX message, creates matching vXXXX tag
• Deployment: Builds Jekyll site with updated version, deploys to GitHub Pages
• Safety: Concurrency control prevents race conditions, validates file existence, checks for duplicate tags

Documentation Updates

• README.md: Added "Versioning and Deployments" section explaining the system
• ROADMAP.md: Marked "Automated Increments" and "Deployment Tagging" as complete

Integration with Main Branch

• Merged latest changes from main: Integrated banner URL fix to ensure compatibility with latest codebase changes

Workflow Sequence

on: push to main
  → Read VERSION.txt (e.g., 1500)
  → Increment (→ 1501)  
  → Build Jekyll site (footer shows "rev.1501.")
  → Commit VERSION.txt
  → Tag as v1501
  → Deploy to GitHub Pages

The footer already displays the version via {% include VERSION.txt %} - this PR automates the increment and tagging.

Checklist

• Build runs successfully
• VERSION.txt format preserved (no trailing newline)
• Error handling for missing files and duplicate tags
• Documentation updated
• Merged latest changes from main branch

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Site version</issue_title>
<issue_description>1. I want to track each "deploy to production" which means I need some way to automatically tag and identify releases
2. This should be done as part of the CI system. Anything that gets merged into master (or better yet #797 main) should get tagged with a release number and incremented</issue_description>

<agent_instructions>Read through the entire Issue, there have been new updates. If you are unsure about what to do, ask.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@ckenst This might end up being a site version that gets deployed to the site itself.

Summary of the Flow

1. You push changes to main.

2. The GitHub Action runs.

3. It reads the VERSION file (X), calculates the new version (X+1), and overwrites the file.

4. It builds your Jekyll site.

5. It automatically creates a new commit on main that only contains the updated VERSION file.

6. It deploys the entire site (including the new version number) to GitHub Pages.</comment_new>
   <comment_new>@ckenst
   I've added the VERSION file and some other beginning things like where to put the VERSION in the footer in this commit 215a628</comment_new>
   <comment_new>@ckenst
   Additional updates:

7. Version file is now in the _includes folder: https://github.com/TestingConferences/testingconferences.github.io/blob/main/_includes/VERSION.txt

8. This is then included in the footer using rev.{% include VERSION.txt %}.

9. The goal is still to increment the VERSION number on pushes to main. We want to read the VERSION file (X), calculate the new version (X+1). This way we can track all deployments and then take measurements (later) for each deployment.

10. We should also ensure every production deploy is tagged in Git to match the internal version.

11. Update the Roadmap to check off Automated Increments and Deployment Tagging</comment_new>

• Fixes Site version #812

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[ckenst]

@copilot please pull in the latest from main. That should fix the CI build.

[Copilot]

@copilot please pull in the latest from main. That should fix the CI build.

Merged latest changes from main branch in commit 7b7d7c1. The branch now includes the banner URL fix and should resolve the CI build issue.