-
Notifications
You must be signed in to change notification settings - Fork 11.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce frequency of version comment updates #4244
Conversation
|
@@ -16,7 +16,7 @@ const { version } = require('../../package.json'); | |||
const [tag] = run('git', 'tag') | |||
.split(/\r?\n/) | |||
.filter(semver.coerce) // check version can be processed | |||
.filter(v => semver.lt(semver.coerce(v), version)) // only consider older tags, ignore current prereleases | |||
.filter(v => semver.satisfies(v, `< ${version}`)) // ignores prereleases unless currently a prerelease |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I was thinking you proposed semver.lt(v, version)
instead.
Anyway, I think they're equivalent, in that case, how does this avoid that at the moment of releasing 5.0.0
, we'll still have 4.9.0.rc-2
?
Correct me if wrong, but I think that's solved if the semver.coerce
in line 18 filters the 4.9.0,rc-1
. But then, how is this not equivalent to the previous version (semver.lt(semver.coerce(v), version)
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
semver.coerce('v4.9.0-rc.0')
returns '4.9.0'
, i.e. it removes the prerelease part. That's why I'm removing it in this PR.
The other important bit is that lt
and satisfies + <
behave differently...
lt
: 4.8.3 < 4.9.0-rc.0 < 4.9.0-rc.1 < 4.9.0satisfies
: 4.8.3 < 4.9.0-rc.0 < 4.9.0-rc.1, but not 4.9.0-rc.1 < 4.9.0.
As a result, at the moment of releasing 4.9.0 we will ignore all the 4.9.0 prereleases and update the changed files since 4.8.3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Lets keep in mind to check the the release code before pushing to npm
(cherry picked from commit 1642b66)
In #4243 we see that every file changed in 4.9.0-rc.0 is getting its version header bumped again to 4.9.0-rc.1 even though only one file is updated in rc.1.
The change in this PR is subtle but causes the effect we want.
When bumping from v4.9.0-rc.0 to v4.9.0-rc.1, it compares against the v4.9.0-rc.0 tag to figure out what files to update. When bumping from v4.9.0-rc.1 to v4.9.0, it compares against the v4.8.3 tag to figure out what files to update.