Skip to content

Support legacy value for --latest when creating/editing a release #13828

Description

@filiphr

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementa request to improve CLI

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions