release 0.5.0
idiomatic opened this issue ยท 24 comments
- confirm 2cbaeea (or later) archive works with WoW client [@JanGalek or volunteer]
- bump version to 0.5.0
- add ceremonial CHANGELOG.txt entry
- beta release to CurseForge [@idiomatic, to monitor new deploy tech]
- release to CurseForge [@JanGalek, via GitHub Actions]
Shadowlands not launch 2020-10-27 ;), it was postponed. Shadowlands will be this year, but nobody know when (COMING 2020).
decoupling from Shadowlands then.
(before expansions is a good time for players to "catch up" on achievements.)
You can automate release for CurseForge - https://authors.curseforge.com/knowledge-base/projects/3451-automatic-packaging (so you can work only there on github :) )
It's good to know there's another CurseForge-specific option.
For now, I'm happy with the (general-purpose "marketable" skills) GitHub Actions solution, based on https://github.com/BigWigsMods/packager.
On the topic of release management: I do have a minor concern whether the publish action should force updating latest submodules before archiving. If it's automatic (as it is currently coded), it is one fewer thing to forget to update on regular releases. On the other hand, it would require "trickery" for forks or branches to override which AchievementLocations or Ace3 versions submodule. For now, I'll err on the side of being more convenient magical for the majority of the use case.
I'm happy that I can confirm that master works with actual version of WoW Client ;)
Due to increased caution -- thanks to last-minute discovery that GitHub Actions Ubuntu has noticeably obsolete packages -- tonight's release is downgraded to beta.
We shall do a "release" release shortly.
@idiomatic yes, I want try it :)
0.5.0 beta has exceeded 200 downloads and no new issues have come in, so I'm ok with "release" release.
@JanGalek, do you want to give it a try and "pull the trigger"?
hint: go to Publish to CurseForge Action and click the Run workflow
, and enter release
.
(I had forgotten there were archives attached to this project within GitHub proper. is this something worth engineering into the GitHub Actions workflows?)
@JanGalek congrats!
@idiomatic Thank you :)
One small concern: the release does not have the version number burned into the "zip" archive filename. Do you think we should add that for releases builds?
It would be challenging as the GitHub Actions workflow does not have the same scriptability or deferability as the Makefile. The Makefile has the ability to lazily determine the VERSION from the TOC file, and as the Makefile is contained within the repo, it is after the git clone which supplies the TOC file.
Option 1 would be to use some set-output
from the Makefile and feed that into the workflow's ARCHIVE variable, if the release-type warrants it.
Option 2 would be to omit ARCHIVE from the workflow and just trust the Makefile layer to selectively add version.
Do you mean for name of zip ? I think it should not be problem, but I can add it ;)
Manually adding the version to the path is discouraged. In fact, I want to avoid any uploading of release artifacts. I've witnessed too many release engineering catastrophes to trust desktop PCs or avoidable manual steps.
Let me pivot my concern: Is it still customary to have version numbers to the filename of archive WoW AddOns?
If so, I'll own the remedy.
We can try automate it, for example when we push tag (postfix alpha/beta will create alpha/beta version and without postfix will create release)
We can try [to] automate it.
Now you understand my motivation for continued involvement in this project: practicing CI/CD.