-
Notifications
You must be signed in to change notification settings - Fork 60
fix(ng-dev): publishing fails if pre-release is cut for new minor/major #126
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
Conversation
josephperrott
left a comment
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.
Overall LGTM
Probably worth having @clydin and/or @AndrewKushnir take a look as well.
This comment has been minimized.
This comment has been minimized.
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
46bcb8e to
80442fb
Compare
be690d5 to
0d07ec3
Compare
josephperrott
left a comment
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
0d07ec3 to
672a1fd
Compare
Currently publishing fails if a pre-release is cut for an upcoming major/minor. This is because the `next` release-train has some special logic where its version is already bumped, but the version has not been released. Our release notes logic currently when building a pre-release for next, looks for a tag named similar to the version in the `package.json`. This will always fail. To fix this, we consult the release trains for building up the Git range that is used for the release notes. We still rely on tags, but we determine the tags from the active release trains (which is more robust than relying on the package json value). For the special `next` release-train situation, we build up the release notes from the most recent patch to `HEAD` of next. While doing this, we also dedupe any commits that have already landed in patch, RC, or FF releases.
672a1fd to
3fd550c
Compare
|
@jelbourn I've merged this to unblock other work on the release tool (and to make the tool usable as soon as possible). I'd still appreciate your review on the PR when you get time (especially on the tests for the changelog generation). No rush. |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently publishing fails if a pre-release is cut for an upcoming
major/minor. This is because the
nextrelease-train has somespecial logic where its version is already bumped, but the
version has not been released. Our release notes logic currently
when building a pre-release for next, looks for a tag named
similar to the version in the
package.json. This will always fail.To fix this, we consult the release trains for building up
the Git range that is used for the release notes. We still
rely on tags, but we determine the tags from the active release
trains (which is more robust than relying on the package json value).
For the special
nextrelease-train situation, we build up therelease notes from the most recent patch to
HEADof next. Whiledoing this, we also dedupe any commits that have already landed in
patch, RC, or FF releases.