Closed ptheywood closed 3 years ago
Two main Release Workflow options.
At this point, we need to decide on versioning (exactly).
Current plan is to use SemVer.
I.e. FLAME GPU2 MAJOR.MINOR.PATCH[-PRE.RELEASE.STUFF]
If we're planning to publish to pypi, we must follow PEP440, which supports SEMVER, but also supports date based schemes as the alternative (i.e. 2012.4
).
Assuming we follow semver, we need to take a little care with the python version number re: pre-release builds.
CUDA_ARCH
for this.So, the options are:
0.
, for non-stable API
FLAME GPU 2 0.0.0-alpha
/ python 0.0.0a
2.
, to avoid confusion with FLAME GPU 1.x
FLAME GPU 2 2.0.0-alpha
/ python 2.0.0a
FLAME GPU 2 2021.07
. vX.Y.Z[-P])
perform a thorough build (above), storing relevant files as archive.Pros:
Alternatively, if the pushing of a tag to github is skipped and a new tag is created via the new release UI
Pros:
0.
for semver implications2.
to minimise confusion@mondus @Robadob @MILeach
Personally, i'm in favour of:
v2.MINOR.PATCH-PRERELEASE
2.0.0-alpha
. 2.0.0
as the first non-pre release when we've finalised the initial API.2.1.0-rc1
mark release candidates for testing (and potentially not upload them to pypy?)
What exact versioning scheme do we want to use. I agree that
YYYY.MM.patch
doesn't really make sense unless we want to commit to a regular release schedule (which I don't think we should). Less concerned about the 0 vs 2 thing.Binary Release Build Matrix
- Tag-based or Release Based actions / workflow.
Meeting decisons:
2.0.0-alpha
(or maybe 2.0.0-pr1
) Will need install instructions on the docs, via wheel / zip download
Releases are tagged commits with extra information (prerelease?, description, extra zip files etc) which can then be used with predictable download locations (for zip download).
For FLAMEGPU 1, when we create a (minor?) release we also manually attach a zip file containing the compiled executables for windows, using the visual studio and CUDA versions within the vcxproj files, so users do not have to compile code to try FLAME GPU.
For FLAME GPU 2 we can continue and automate this tradition (through github actions). We could also attach artifacts containing python related parts, or the library + headers.
GitHub Actions can be triggered for both
push.tag
events andrelease
events.When a new tag is pushed to github the
on.push.tags
event is triggered (can be filtered by tag name). This includes new tags created by creating new releases from untagged commits through the github releases UI.Release events are assocaited with a given tag, either pre-existing or newly created through the UI. There are 6 types of release events. Actions only occur for non-draft releases.
published
- when an event is made non-draftunpublished
- never acted upon, as unpublished === draft.created
- when a new release is created and published at the same time (can be created but unpublished, so action does not trigger)edited
- when the text of the release is modified, but not when the tag is changed (during testing)deleted
- when a published release is deletedprereleased
- when a published release is mared as a pre-release (creation or edit)released
- when a published release is marked as not pre-release (creation or edit)Release Proposal(s)
Option 1 - manual releases
tag
events, trigger more thoroguh CI (all supported compute capabilities on all supported platforms) (if not already triggered for that commit?)release
events of the typespublished
build artifacts, and attach to the releaseNew releases should always be created pre-release, and only marked as release once we are confident in the release (i.e. all tests + maybe manual tests).
Once we have GPU enabled actions (#97) we could automate/enforce the release/pre-release status.
pre-release
events, run the gpu-enabled CI test suties - if it passes mark as arelease
released
events, if the mode detailed CI has not been ran, mark it as pre-releaseThere is an edge case where if the tag which a release points to is changed, it does not trigger a release event - The solution is to not change release tags. Alternatively it may be possibly to run an action on push.tag events, which checks for an existing release associated with that commt hash via the api.
We may also need to restrict the author of the tag (not sure how PRs from forks with tags work, but we don't want to do this for external tags without explicit support)
Option 2 - automatic releases based on tags.
On
tag
events trigger the more thorough CI / actual tests. If it passes, create a new release based on the tag, and attach relevant artefacts. This would likely need the thorough build to include multiple jobs for the respective OS's being tested:A mechanism for getting the changelog for the description would be required.
I've made this separate to #290 as it's lower priority / longer-term.