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

v0.5.8 README #654

Merged
merged 2 commits into from
Mar 25, 2020
Merged

v0.5.8 README #654

merged 2 commits into from
Mar 25, 2020

Conversation

yuanming-hu
Copy link
Member

@yuanming-hu yuanming-hu commented Mar 25, 2020

Trying to separate visible changes from underlying development ("Full log"). Let me know if this makes sense to you guys. We should end up with a formal and consistent format for the release log.

Maybe every PR author should keep in mind that their PR titles will be potentially part of the release log.

[Click here for the format server]

@yuanming-hu yuanming-hu requested review from archibate and k-ye March 25, 2020 05:16
@k-ye
Copy link
Member

k-ye commented Mar 25, 2020

Looks good!

BTW, in my team we have a few tags like this:

new

  • feature1
  • feature2

fixes

  • bug1
  • bug2

other tags

...

Would that make it easier to write this log? (But i do see other project's commits with a pattern of [XX] Title of a PR, so probably this in the standard approach..)

@yuanming-hu
Copy link
Member Author

yuanming-hu commented Mar 25, 2020

Looks good!

BTW, in my team we have a few tags like this:

new

  • feature1
  • feature2

fixes

  • bug1
  • bug2

other tags

...

Would that make it easier to write this log? (But i do see other project's commits with a pattern of [XX] Title of a PR, so probably this in the standard approach..)

I agree. Updated the list. As we have more and more contributions/releases, it's worth considering making the changelog generation automatic. I propose that we always prepend a PR tag such as [Metal backend] to the PR title.

In addition, although we do appreciate all kinds of contributions, we should not expose every PR to the end-users - otherwise, users will get rather confused when seeing a super long changelog. We should use the releases page for the full changelog.

I suggest that we follow this simple rule:

  • PRs with visible/notable features to the users should be marked with tags starting with first letter capitalized, e.g. [Metal backend], [OpenGL backend], [IR], [Lang], [CLI],
  • Other PRs (underlying development/intermediate implementation) should use tags with everything in lower-case: e.g. [metal backend], [opengl backend], [ir], [lang], [cli]

I believe this will not only make generating the changelog easier, but also make the PRs more organized. What do you think? @k-ye @archibate If we all agree I'll put it in the contributor guideline.

A list of tags: (feel free to propose more. We can also invent more tags when merging PRs.)
[Metal backend], [OpenGL backend], [CPU backend], [CUDA backend], [IR], [Lang], [CLI], [Util], [Infra], [Misc] (Infra is for low-level infrastructure)

@yuanming-hu
Copy link
Member Author

I'm merging this in so that people can see a change log in time. Feel free to continue the discussions! Thanks.

@yuanming-hu yuanming-hu merged commit 2d1c023 into master Mar 25, 2020
@yuanming-hu yuanming-hu deleted the 0.5.8-readme branch March 25, 2020 15:41
archibate pushed a commit to archibate/taichi that referenced this pull request Mar 31, 2020
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.

2 participants