Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: lmoureaux/freeciv21
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: v10.0
Choose a base ref
...
head repository: lmoureaux/freeciv21
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: bugfix/release-tarballs-branch
Choose a head ref
  • 9 commits
  • 5 files changed
  • 2 contributors

Commits on Feb 11, 2023

  1. Copy the full SHA
    4546cc0 View commit details
  2. Copy the full SHA
    a29719d View commit details
  3. Copy the full SHA
    f550ac5 View commit details
  4. Use the new CI syntax to set job outputs

    lmoureaux authored and jwrober committed Feb 11, 2023
    Copy the full SHA
    f6bb71a View commit details

Commits on Feb 12, 2023

  1. Don't hard code master for autorevision and source tarballs

    We released 3.0-rc.3 with code from master. This should not happen.
    lmoureaux committed Feb 12, 2023
    Copy the full SHA
    551700f View commit details
  2. Make the AutoRevision update PR against the tagged branch

    We need to update AutoRevision.txt in both the stable and master branches, so
    try to do that automatically.
    lmoureaux committed Feb 12, 2023
    Copy the full SHA
    a896ce8 View commit details
  3. AutoRevision PR: state which branch is updated

    Just to make sure the information is visible.
    lmoureaux committed Feb 12, 2023
    Copy the full SHA
    d5f627a View commit details
  4. Document the procedure when releasing the first RC

    * Update the stable branch to follow the new release
    * Make RC releases from the stable branch
    * Bump the version number on master
    lmoureaux committed Feb 12, 2023
    Copy the full SHA
    12b9239 View commit details
  5. Docs: Mention the stable branch in the intro of the Release page

    lmoureaux committed Feb 12, 2023
    Copy the full SHA
    27ef285 View commit details
Showing with 55 additions and 18 deletions.
  1. +5 −1 .gitattributes
  2. +1 −1 .github/workflows/build.yaml
  3. +14 −3 .github/workflows/release.yaml
  4. +20 −3 docs/Contributing/release.rst
  5. +15 −10 docs/Contributing/stable-branch.rst
6 changes: 5 additions & 1 deletion .gitattributes
Original file line number Diff line number Diff line change
@@ -1,5 +1,9 @@
# don't export these files
data/graphics/** export-ignore
data/graphics/** export-ignore
.coverity/** export-ignore
.github/** export-ignore
.gitlab-ci.yaml export-ignore
.readthedocs.yaml export-ignore

# text files
* text=auto
2 changes: 1 addition & 1 deletion .github/workflows/build.yaml
Original file line number Diff line number Diff line change
@@ -232,7 +232,7 @@ jobs:
env:
BRANCH: ${{github.ref_name}}
id: split
run: echo "::set-output name=fragment::${BRANCH##*/}"
run: echo "fragment=${BRANCH##*/}" >> $GITHUB_OUTPUT
- name: Create App Bundle
run: |
mkdir -p Freeciv21.app/Contents/MacOS Freeciv21.app/Contents/Resources
17 changes: 14 additions & 3 deletions .github/workflows/release.yaml
Original file line number Diff line number Diff line change
@@ -10,19 +10,31 @@ jobs:
- uses: actions/checkout@v3
with:
fetch-depth: 0
ref: master
- # Make sure there are no unstaged changes
# Was reporting changes to eol=crlf files in .gitattributes
run: git checkout -- .
- run: git rev-parse --short=5 HEAD > cmake/AutoRevision.txt
- run: git describe --tags `git rev-list --tags --max-count=1` >> cmake/AutoRevision.txt
- run: cat cmake/AutoRevision.txt
- name: Find target branch
id: branch
# We're running on a tag so have no direct access to the branch. Find it.
# Strip the first 3 components (ref/remotes/username)
run: |
git diff branch=$(git branch -r --contains HEAD --format '%(refname:strip=3)')
echo Target branch is $branch
echo branch=$branch >> $GITHUB_OUTPUT
- name: Create Pull Request
uses: peter-evans/create-pull-request@v4.0.4
with:
base: ${{ steps.branch.outputs.branch }}
commit-message: "Release update of AutoRevision.txt"
branch: "release/autorevision"
branch: release/autorevision/${{ steps.branch.outputs.branch }}
title: "Release update of AutoRevision.txt"
body: >
Automatic changes triggered by a new release.
This PR updates `${{ steps.branch.outputs.branch }}`.
Close and reopen this pull request to start the CI.
delete-branch: true
update-archive:
@@ -32,7 +44,6 @@ jobs:
- uses: actions/checkout@v3
with:
fetch-depth: 0
ref: master
- run: git rev-parse --short=5 HEAD > cmake/AutoRevision.txt
- run: git describe --tags `git rev-list --tags --max-count=1` >> cmake/AutoRevision.txt
- run: cat cmake/AutoRevision.txt
23 changes: 20 additions & 3 deletions docs/Contributing/release.rst
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
..
SPDX-License-Identifier: GPL-3.0-or-later
SPDX-FileCopyrightText: 2022 James Robertson <jwrober@gmail.com>
.. SPDX-License-Identifier: GPL-3.0-or-later
.. SPDX-FileCopyrightText: 2022 James Robertson <jwrober@gmail.com>
.. SPDX-FileCopyrightText: Louis Moureaux <m_louis30@yahoo.com>s
The Release Process
*******************
@@ -11,6 +11,10 @@ use the term "loosely" as there is a large amount of discretion with regard to t
a release at any time to fix a nasty bug or slow a release down to get in a PR a developer is really close
to completing and wants it in the next release. However, we do aim to release around 6 to 8 times per year.

Pre-releases are done from the ``master`` branch, while release candidates and stable releases use the
``stable`` branch, which contains bug fixes backported from master. See
:doc:`the dedicated page <stable-branch>` for how this is done.

These are the general steps to prepare and finalize a release:

#. A release manager will open a draft release notes page from: https://github.com/longturn/freeciv21/releases.
@@ -26,6 +30,19 @@ These are the general steps to prepare and finalize a release:
need to delay in any way or if we are good to proceed as normal.
#. When it is time, the release manager will finalize the release notes and ask for an editorial review in the
``#releases-project`` channel. Updates are made as per review.
#. If the release will be the :strong:`first release candidate` towards a stable release, the release manager
will:

#. Delete the existing ``stable`` branch on Github's
`branches page <https://github.com/longturn/freeciv21/branches>`_.
#. From the same page, create a new ``stable`` branch from ``master``.
#. Update ``cmake/AutoRevision.txt`` with the hash of the last commit in ``master`` and
``v[major version].[minor version]-dev`` with the version of the :strong:`next stable release`, then
open a PR for this change to ``master``. This way, development builds from ``master`` will immediately
use the version number of the next stable.

#. If the release is a :strong:`release candidate` or a :strong:`stable release`, the release manager will
make sure that the :guilabel:`Target` branch in the release draft is set to ``stable``.
#. The release manager will add a tag to the release notes page and then click :guilabel:`Publish Release`.
The format of the tag is ``v[major version].[minor version]-[pre-release name].[number]``. For example:
``v3.0-beta.6``. :strong:`The format is very important` to the build configuration process.
25 changes: 15 additions & 10 deletions docs/Contributing/stable-branch.rst
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-3.0-or-later
.. SPDX-FileCopyrightText: 2023 James Robertson <jwrober@gmail.com>
.. SPDX-FileCopyrightText: James Robertson <jwrober@gmail.com>
.. SPDX-FileCopyrightText: Louis Moureaux <m_louis30@yahoo.com>
Maintaining the Stable Branch
*****************************
@@ -14,6 +15,8 @@ occasions where we are introducing major breaking changes that take time to reso
``stable`` branch. As development occurs on the ``master`` branch, there are going to be times when we want to
back-port a commit (a single patch) or a Pull Request (a collection of commits) over to the ``stable`` branch.

The ``stable`` branch is created when preparing for the first Release Candidate towards a stable release, see
:doc:`release`.
This page documents the rules and procedures for maintaining the ``stable`` branch.

Requirements for a Back-Port
@@ -40,8 +43,8 @@ Tagging Commits for Back-Port

When a community member authors and publishes a :doc:`Pull Request (PR) <pull-request>`, they can add text to
the primary comment that the PR is a back-port candidate. If the whole PR is not a candidate, but a specific
commit within the PR is, then this distinction should be highlighted as part of the comment. The Commit ID is
the definitive reference point to reduce ambiguity.
commit within the PR is, then this distinction should be highlighted as part of the comment. The full Commit
ID is the definitive reference point to reduce ambiguity.

As is customary, all PRs should target the ``master`` branch.

@@ -50,18 +53,20 @@ Who Approves a Back-Port Request?

As is our standard, every Pull Request (PR) must have a peer review approval before a merge. The person
assigned this task has the authority to approve or deny the back-port request. This authority comes with a
catch; the peer reviewer must add the commit(s) to a back-port tracker sheet that the admins will use to
keep track of patches that need to be back-ported.
catch; the peer reviewer must add the commit(s) to a back-port project that the admins will use to keep track
of patches that need to be back-ported.

The tracker sheet is here: https://docs.google.com/spreadsheets/d/1W7YIv-SN1ZOKQdYfESzltx1nsaEc_qogH-GLEarCxEY/edit?usp=sharing
The back-port project is here: https://github.com/orgs/longturn/projects/3. You can find it by going to the
main Longturn GitHub repository page and click on the projects tab.

Editing access is restricted. Ask an admin on the ``#releases-project`` channel on the ``LT.DEV`` section of
our Discord server. The columns of the tracker sheet are simple enough to follow.
As part of the review process, simply tag the PR to the project and add a ``back-port`` label to aid tracking.
Once the PR has been merged into ``master``, go get the commit ID(s) and add those to the appropriate column
in the project. Multiple Commit IDs should be separated by a space.

Maintaining Tracked Back-Port Commit Candidates
===============================================

On a periodic basis, for example every two or three weeks, an administrator will open the sheet and use the
On a periodic basis, for example every two or three weeks, an administrator will open the project and use the
information to build a commit cherry-pick file for ``git`` to use.

Follow these steps:
@@ -70,4 +75,4 @@ Follow these steps:
#. Copy and paste the values of the Commit ID column to a plain text file, such as :file:`commits.txt`
#. Run ``git cherry-pick -x $(cat commits.txt)``
#. Push ``stable`` to upstream: ``git push upstream``
#. Update the tracker sheet to denote which commits where back-ported.
#. Update the project sheet to denote which commits were back-ported.