Describe the feature or problem you’d like to solve
When creating a release with gh release create, the --latest flag currently only accepts a boolean (true/false), and when it is omitted the make_latest field is not sent to the API at all.
However, the GitHub REST API's Create a release endpoint accepts three values for the make_latest body parameter:
true, false, legacy
Specifies whether this release should be set as the latest release for the
repository. Drafts and prereleases cannot be set as latest. Defaults to true
for newly published releases. legacy specifies that the latest release should
be determined based on the release creation date and higher semantic version.
The legacy value is currently not reachable through the CLI. There is no way to tell the CLI "pick the latest release based on creation date + highest semver" the way the API allows.
The current --latest help text is also incorrect
The flag is currently documented as:
Mark this release as "Latest" (default [automatic based on date and version]). --latest=false to explicitly NOT set as latest
This description is wrong. Per the REST API, make_latest defaults to true for newly published releases — i.e. the release is made the latest. The behavior described in the help text ("automatic based on date and version") is actually what the legacy value does, not the default. So the help text is describing legacy behavior as if it were the default.
This should be corrected regardless of whether legacy support is added, and ideally would be updated alongside it.
Proposed solution
Allow --latest to accept legacy in addition to true/false.
The --latest flag is currently registered as a nil-able boolean:
cmdutil.NilBoolFlag(cmd, &opts.IsLatest, "latest", "",
`Mark this release as "Latest" (default [automatic based on date and version]). --latest=false to explicitly NOT set as latest`)
and serialized like this:
if opts.IsLatest != nil {
// valid values: true/false/legacy
params["make_latest"] = fmt.Sprintf("%v", *opts.IsLatest)
}
Note the code comment already documents true/false/legacy as valid values, but because IsLatest is a *bool, legacy can never actually be passed.
A possible approach would be to change the flag from a nil-able bool to a string-valued flag (e.g. via cmdutil.StringEnumFlag) accepting true, false, and legacy, while still forwarding the value straight through to make_latest. Omitting the flag would keep the current behavior of not sending make_latest.
Backwards compatibility must be preserved. Any change should keep the existing usage working exactly as it does today:
--latest (bare flag, no value) must continue to mean true.
--latest=true and --latest=false must continue to behave as they do now.
- Omitting
--latest must continue to leave make_latest unset (unchanged default behavior).
Only the additional legacy value would be new.
The same change would be relevant for gh release edit, which also exposes a --latest flag and should accept legacy consistently with gh release create.
Additional context
Describe the feature or problem you’d like to solve
When creating a release with
gh release create, the--latestflag currently only accepts a boolean (true/false), and when it is omitted themake_latestfield is not sent to the API at all.However, the GitHub REST API's Create a release endpoint accepts three values for the
make_latestbody parameter:The
legacyvalue is currently not reachable through the CLI. There is no way to tell the CLI "pick the latest release based on creation date + highest semver" the way the API allows.The current
--latesthelp text is also incorrectThe flag is currently documented as:
This description is wrong. Per the REST API,
make_latestdefaults totruefor newly published releases — i.e. the release is made the latest. The behavior described in the help text ("automatic based on date and version") is actually what thelegacyvalue does, not the default. So the help text is describinglegacybehavior as if it were the default.This should be corrected regardless of whether
legacysupport is added, and ideally would be updated alongside it.Proposed solution
Allow
--latestto acceptlegacyin addition totrue/false.The
--latestflag is currently registered as a nil-able boolean:and serialized like this:
Note the code comment already documents
true/false/legacyas valid values, but becauseIsLatestis a*bool,legacycan never actually be passed.A possible approach would be to change the flag from a nil-able bool to a string-valued flag (e.g. via
cmdutil.StringEnumFlag) acceptingtrue,false, andlegacy, while still forwarding the value straight through tomake_latest. Omitting the flag would keep the current behavior of not sendingmake_latest.Backwards compatibility must be preserved. Any change should keep the existing usage working exactly as it does today:
--latest(bare flag, no value) must continue to meantrue.--latest=trueand--latest=falsemust continue to behave as they do now.--latestmust continue to leavemake_latestunset (unchanged default behavior).Only the additional
legacyvalue would be new.The same change would be relevant for
gh release edit, which also exposes a--latestflag and should acceptlegacyconsistently withgh release create.Additional context