Closed MattSturgeon closed 8 months ago
Note: I wasn't using my normal machine when working on this, so it's currently in untested-draft status
This is now resolved. Ready for review 😃
Going to look over this PR now. Just want to confirm that this doesn't break backwards compatibility for people using GitHub publishing?
These new features only have any affect when they are explicitly configured?
Just want to confirm that this doesn't break backwards compatibility for people using GitHub publishing?
These new features only have any affect when they are explicitly configured?
For target_committish
, we're changing how we use github API, but that shouldn't change behavior. Previously, you were explicitly setting the default value.
For draft
, the default is still false
. The only change in this scenario is that we won't explicitly set draft=false
if the release is already not a draft.
I've tried to make draft promotion a directional thing; you can promote a draft release to a public release, but not the other way round. Of course, the API supports both directions, but I felt it made more sense to hide that with an abstraction.
If you are happy with everything, this should be good to go
If you are happy with everything, this should be good to go
Wonderful :heart:
Do you want the history squashed/cleaned?
If you are happy with everything, this should be good to go
Wonderful ❤️
Do you want the history squashed/cleaned?
Thanks for that cleanup. I changed it, but forgot to commit. Fun part of being busy with 3 things at once :sweat_smile:
I'll do a squash and merge, so should be fine :)
I'll do a squash and merge, so should be fine :)
I ended up rebasing anyway whiel fixing up the changelog, so squashing probably isn't needed
Following on from #8:
Welcome to the future :rocket:
Introduce some additional control over the GitHub Release publishing:
target_commitish
; used if GitHub creates the release's tag.Note: I wasn't using my normal machine when working on this, so it's currently in untested-draft status 😃
I'm going to say this fixes #7. That issue is probably too vague to be useful going forward; the available options can always be improved.