1
0
mirror of https://github.com/EDCD/EDMarketConnector.git synced 2025-04-17 17:42:20 +03:00

Releasing.md: Cursory update for Semantic Versions

This commit is contained in:
Athanasius 2020-07-18 18:04:33 +01:00
parent 4435bb004a
commit 3abd4455df

View File

@ -50,7 +50,7 @@ There are other things that you should probably change, but can get away with le
1. appname: The short appname, e.g. 'EDMarketConnector' 1. appname: The short appname, e.g. 'EDMarketConnector'
1. applongname: The long appname, e.g. 'E:D Market Connector' 1. applongname: The long appname, e.g. 'E:D Market Connector'
1. appcmdname: The CLI appname, e.g. 'EDMC' 1. appcmdname: The CLI appname, e.g. 'EDMC'
1. appversion: The current version, e.g. '3.5.0.0' 1. appversion: The current version, e.g. '4.0.2'
1. update_feed: The URL where the application looks for current latest 1. update_feed: The URL where the application looks for current latest
version information. This URL should be hosting a renamed (so the full URL doesn't change over application versions) version of the appcast_win_<version>.xml file. The original upstream value is `https://raw.githubusercontent.com/EDCD/EDMarketConnector/releases/edmarketconnector.xml`. version information. This URL should be hosting a renamed (so the full URL doesn't change over application versions) version of the appcast_win_<version>.xml file. The original upstream value is `https://raw.githubusercontent.com/EDCD/EDMarketConnector/releases/edmarketconnector.xml`.
@ -67,20 +67,20 @@ Before you create a new install each time you should:
Preparing to Package Preparing to Package
=== ===
**Version numbers should always be referred to in full, e.g. A.B.C.D not the **Version numbers should always be referred to as, e.g. A.B.C not the
old A.BC scheme.** old A.BC scheme, nor the pre-Semantic Version A.B.C.D scheme.**
We'll use an old version number, 3.5.0.0, as an example throughout the We'll use an old version number, 4.0.2, as an example throughout the
following. following.
1. You should by this time know what changes are going into the release, and 1. You should by this time know what changes are going into the release, and
which branch (stable or beta) you'll be ultimately updating. which branch (stable or beta) you'll be ultimately updating.
1. So as to make backing out any mistakes easier create a new branch for this 1. So as to make backing out any mistakes easier create a new branch for this
release, using a name like `release-3.5.0.0`. Do not use the tag release, using a name like `release-4.0.2`. Do not use the tag
`Release/3.5.0.0` form, that could cause confusion. `Release/4.0.2` form, that could cause confusion.
1. `git checkout stable` # Or whichever other branch is appropriate. 1. `git checkout stable` # Or whichever other branch is appropriate.
1. `git pull origin` # Ensures local branch is up to date. 1. `git pull origin` # Ensures local branch is up to date.
1. `git checkout -b release-3.5.0.0` 1. `git checkout -b release-4.0.2`
1. Get all the relevant code changes into this branch. This might mean 1. Get all the relevant code changes into this branch. This might mean
merging from another branch, such as an issue-specific one, or possibly merging from another branch, such as an issue-specific one, or possibly
@ -113,7 +113,7 @@ a `stable` release, as well as any social media posts you make.
1. Update the `url`, `sparkle:version` and `length` elements of the 1. Update the `url`, `sparkle:version` and `length` elements of the
`<enclosure>` section as per the latest `EDMarketConnector_win_<version>.msi` `<enclosure>` section as per the latest `EDMarketConnector_win_<version>.msi`
file generated by the build process. file generated by the build process.
1. As you're working in a version-specific branch, `release-3.5.0.0`, you 1. As you're working in a version-specific branch, `release-4.0.2`, you
can safely commit these changes and push to GitHub. can safely commit these changes and push to GitHub.
**Do not merge the branch with `releases` until the GitHub release is in **Do not merge the branch with `releases` until the GitHub release is in
place.** place.**
@ -164,14 +164,14 @@ to be included in the install. If they're not picked up by current rules in
`setup.py` then you will need to add them to the `win32` `DATA_FILES` array. `setup.py` then you will need to add them to the `win32` `DATA_FILES` array.
You should now have one new/updated folder `dist.win32` and two new files You should now have one new/updated folder `dist.win32` and two new files
(version number dependent): `EDMarketConnector_win_3.5.0.0.msi` and (version number dependent): `EDMarketConnector_win_4.0.2.msi` and
`appcast_win_3.5.0.0.xml`. `appcast_win_4.0.2.xml`.
Now check that the `EDMarketConnector.exe` in the `dist.win32` folder does run Now check that the `EDMarketConnector.exe` in the `dist.win32` folder does run
without errors. without errors.
Finally, uninstall your current version of ED Market Connector and re-install Finally, uninstall your current version of ED Market Connector and re-install
using the newly generated `EDMarketConnector_win_3.5.0.0.msi` file. Check the using the newly generated `EDMarketConnector_win_4.0.2.msi` file. Check the
resulting installation does work (the installer will run the program for you). resulting installation does work (the installer will run the program for you).
Distribution Distribution
@ -180,18 +180,18 @@ Once you have tested the new .msi file:
1. Add a git tag for the release, which you'll refer to when actually creating 1. Add a git tag for the release, which you'll refer to when actually creating
the release: the release:
1. This should be named `Release/A.B.C.D`, e.g. `Release/3.5.0.0.` as per 1. This should be named `Release/A.B.C`, e.g. `Release/4.0.2.` as per
the version number. the version number.
1. Now push the release-specific branch to GitHub. 1. Now push the release-specific branch to GitHub.
1. Check which of your remotes is for github with `git remotes -v`. It 1. Check which of your remotes is for github with `git remotes -v`. It
should really be `origin` and the following assumes that. should really be `origin` and the following assumes that.
1. `git push --set-upstream --tags origin release-3.5.0.0` 1. `git push --set-upstream --tags origin release-4.0.2`
1. Merge the release-specific branch into the appropriate `stable` or `beta` 1. Merge the release-specific branch into the appropriate `stable` or `beta`
branch. You can either do this locally and push the changes, or do it on branch. You can either do this locally and push the changes, or do it on
GitHub. You'll want to reference `stable` or `beta` in the next step, *not GitHub. You'll want to reference `stable` or `beta` in the next step, *not
the release-3.5.0.0 branch, as it's temporary.* the release-4.0.2 branch, as it's temporary.*
1. Craft a [new github Release](https://github.com/EDCD/EDMarketConnector/releases/new), 1. Craft a [new github Release](https://github.com/EDCD/EDMarketConnector/releases/new),
1. Use the new tag so as to reference the correct commit, along with the 1. Use the new tag so as to reference the correct commit, along with the
@ -221,7 +221,7 @@ EDMC instances to pick up on 'Check for Updates'. The WinSparkle check for
updates specifically targets `https://raw.githubusercontent.com/EDCD/EDMarketConnector/releases/edmarketconnector.xml` updates specifically targets `https://raw.githubusercontent.com/EDCD/EDMarketConnector/releases/edmarketconnector.xml`
as per `config.py` `update_feed`. as per `config.py` `update_feed`.
1. `git checkout releases` 1. `git checkout releases`
1. `git merge release-3.5.0.0` 1. `git merge release-4.0.2`
1. `git push origin` 1. `git push origin`
(Or merge on GitHub). (Or merge on GitHub).