Skip to content
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

Minor fixes for #4999 #5003

Merged
merged 2 commits into from
Aug 8, 2018
Merged

Minor fixes for #4999 #5003

merged 2 commits into from
Aug 8, 2018

Conversation

igrr
Copy link
Member

@igrr igrr commented Aug 3, 2018


* Commit message should be `Release X.Y.Z`

3. Tag the aboce commit, once it is on the master branch. In this project, tags have form `X.Y.Z`, e.g. `2.4.0`, or `X.Y.Z-rcN` for release versions. Notice that there's no `v`at the beginning of the tag. Tags must be annotated, not lightweight tags. To create a tag, use git command (assuming that the master branch is checked out):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"above"

Copy link
Collaborator

@d-a-v d-a-v left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems more simple 👍


* Commit message should be `Release X.Y.Z`

3. Tag the aboce commit, once it is on the master branch. In this project, tags have form `X.Y.Z`, e.g. `2.4.0`, or `X.Y.Z-rcN` for release versions. Notice that there's no `v`at the beginning of the tag. Tags must be annotated, not lightweight tags. To create a tag, use git command (assuming that the master branch is checked out):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly does this mean:

once it is on the master branch

In point 2 above you say "create a commit", here you hint at all the previous being merged already before pushing the tag.

Is the procedure here Make PR with platform+readthedocs -> wait for CI to finish -> push tag -> wait for CI to finish -> squash/merge? Or is it Make PR with platform+readthedocs -> squash/merge -> make new PR with tag -> squash/merge?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally it is just "create a commit, tag it, and push it onto the master branch", but if you wish to do this via a PR, it can be "create a commit and push it onto a new branch, open a PR, wait for it to be green for merging, merge PR (using "rebase" strategy), tag the newly created commit on the master branch". Should I explain both workflows or just the simple one (commit to master)?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@igrr Just the simple one please.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, I think I understand what needs to be done, but I can't help thinking of someone else reading this down the line.

When `draft: true` is set, incorrect commit/tag information is sent to
Github. Override tag/target fields for correct behavior.

Ref. https://github.com/travis-ci/travis-ci/issues/9852
@igrr
Copy link
Member Author

igrr commented Aug 7, 2018

@devyte Updated.

@devyte
Copy link
Collaborator

devyte commented Aug 7, 2018

LGTM!

@devyte devyte merged commit 559a286 into master Aug 8, 2018
@devyte devyte deleted the release_minor_fixes branch December 11, 2018 17:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants