feat: allow always marking releases as stable #1054
Conversation
mistydemeo
force-pushed
the
force-never-prerelease
branch
from
d9ffc84
to
c5b818e
Compare
There was a problem hiding this comment.
i think we need to update this name and we may need to consider updating some of the built in publish jobs to take this into account. e.g. for npm- npm uses the latest tag to indicate that something is stable. it is automatically added to a new publish IFF the semver isn't a pre-release OR there are only published pre-releases. if someone sets this, has non pre-releases and pre-releases, and then publishes a pre-release to npm, it will Not be marked as stable with our current flow, we would have to add the tag flag. not sure how this works for homebrew but i feel like every package manager will have an opinion on this and i suspect most will need some override to behave as expected
cargo-dist-schema/src/lib.rs
Outdated
| @@ -89,6 +89,9 @@ pub struct DistManifest { | |||
| /// Whether to publish prereleases to package managers | |||
| #[serde(default)] | |||
| pub publish_prereleases: bool, | |||
| /// Always publish prereleases as stable, ignoring semver | |||
| #[serde(default)] | |||
| pub always_publish_as_stable: bool, | |||
There was a problem hiding this comment.
i think we might want to call this "force_stable" because we are both publishing as stable and also announcing and so including a stage name might be complicated
There was a problem hiding this comment.
Seems reasonable!
There was a problem hiding this comment.
after some thinking, i think force_latest is the best option. latest often implies stable, but we should use the terminology from the release hosts we are leveraging (npm, github) so it's clear we are simply applying that value
|
Hm, the npm case is interesting. Checking the CI config, it seems we don't tell npm what to do with it. Does that mean that npm itself is also parsing the version to guess whether it's a prerelease or not? |
|
@mistydemeo you got it- i would probably want to test to make sure my memory is correct here but i am pretty sure that's the default behavior. we can override this by using this flag: https://docs.npmjs.com/cli/v10/commands/npm-dist-tag |
|
We did some checking and determined that npm doesn't infer the prerelease status from the version. For example, this is considered to be the "latest": https://www.npmjs.com/package/@mistydemeo/cargodisttest This points to something we could improve in our existing "publish prereleases" stuff, but means we don't have to do anything in this PR. |
mistydemeo
force-pushed
the
force-never-prerelease
branch
from
c5b818e
to
ba1492b
Compare
mistydemeo
force-pushed
the
force-never-prerelease
branch
from
ba1492b
to
2201174
Compare
This adds a new feature which allows users to override our "is this a prerelease" detection.
By default, we use semver mechanics to determine whether a release is a prerelease or not. If it contains anything within the "pre" part of the version number, we mark it as a prerelease. This has several consequences: we won't mark that release as the latest on GitHub, and we won't publish it to sources like Homebrew. This adds a new config flag,
always-publish-as-stable; if set, then we always count the release as stable at publish time regardless of what the version number says.