3.0.0 release notes && release notes automation #1047
Conversation
I use Lerna's conventional commits feature, it works very nicely. |
or maybe like this? |
CHANGELOG.md
Outdated
|
|
||
| Storybook 3.0 is our first fully community-driven release! Notable changes: | ||
| - Move from `@kadira` to `@storybooks` org across [github](https://github.com/storybooks/storybook/), [npm](FIXME), [docs](https://storybooks.js.org/) | ||
| - Upgrade to Webpack2 [PR637](https://github.com/storybooks/storybook/pull/637) |
There was a problem hiding this comment.
This is a bit nitpicky, and really doesn't matter, but you can just include the URL and github will shorten it to a nicer looking link.
Example:
#637
storybook-eol/storybook-addon-graphql#19
https://github.com/storybooks/storybook/pull/637
https://github.com/storybooks/storybook-addon-graphql/pull/19
I think it's a slightly nicer format when viewing issues on github, and it falls back to the correct link when viewing code outside of github.
I'm totally fine using the [PRXXX](link) format if that's the desired format, but since it looks kind of inconsistent in the changelog's history, I thought I'd bring it up.
There was a problem hiding this comment.
@apexskier I just used the PR format since it was already setup that way. I have converted to using normal links, although they don't seem to be collapsing properly (perhaps because I'm viewing them on a fork of the main repo???) Further suggestions much appreciated!
There was a problem hiding this comment.
I think the collapsing will be fixed once merged 😬
|
@aaronmcadam Lerna's conventional commits feature looks great. but it also requires that we get everybody to adopt that style including PRs from community members. Somebody also suggested https://github.com/zeit/release, where the person making the release can manually classify each commit. But I guess it does not know about monorepos. At any rate, it seems like best practices seems to be logging at the commit level. Does this mean we should get smarter about squashing commits and other more serious git usage? |
|
Can we link PR's merged to issues and list those in the CHANGELOG? |
|
I think systems that are based on "hygenic" commits are going to be hard to enforce on a community project unless we want to do a lot of PR rebasing, which sounds like a pain. I would suggest we follow the process we do for Meteor and Apollo, which is to have a So a contributor would add a line to the If we don't want to use |
|
@ndelangen @tmeasday I did a quick experiment of trying to pull out merged PR's that specifically referenced issues in the first line of their body. The rationale being that enforcing hygienic commits is probably too much work, but maybe we can do a better job with PRs. Also Github makes it easy for us to edit PR titles to make them more descriptive. Here is the output of that experiment: Let me know if you think this idea has merit. If so, I can pursue it further. If not, I'm tempted to go with @tmeasday 's suggestion of a manually-curated changelog, but enforced in PRs. |
Do you mean "referenced issues"? I can get behind the idea of updating the PR title instead of changing a changelog file. If it's reliable it's a great middle ground. |
|
@tmeasday Sorry, yes "referenced issues." I updated my comment. OK, that's encouraging. I'll take a more complete pass at this today and we can at least give it a shot. If it turns out to be a pain, we can revert to a manual method later. Thanks! |
|
This is the format generated by https://github.com/ahmdigital/github-publish-release: |
ROADMAP.md
Outdated
|
|
||
| ### Long Term | ||
|
|
||
| * Automatic story generation (and edge case detection) based on propTypes. | ||
| * Angular Support | ||
| * Vue Support | ||
| * UI addons (Add different panels like Action Logger) |
There was a problem hiding this comment.
-* A clear guide to hack React Storybook
I think we need the new one since we've changed everything in the repo.
-* Addon API and addons
-* React Native Support
-* UI addons (Add different panels like Action Logger)
Do we have any place to move it instead of just delete? Could it be cool to show wich roadmap points already done? What do you think about it, maybe right here one more section with the title 'realized steps' or checkboxes?
There was a problem hiding this comment.
I moved it to the root directory, not deleted.
There was a problem hiding this comment.
I mean don't delete this points
…e-notes # Conflicts: # ROADMAP.md
- use plain links to PRs - group closed PRs by issue type
|
I think we're on the right track. If we could do things like extract labels from issues and do something with that in the CHANGELOG, that could be very useful? For example to categorise per addon / app? |
|
I've always asked (or automated asking) contributors to add CHANGELOG entries from a user's perspective. Trying to automate it from PRs and commits has never worked for me as their audience is different (targeted at devs) |
|
I think making PR titles more "user focused" is ok even if commits remain
developer focused?
…On Sat, 20 May 2017 at 12:03 am, Orta ***@***.***> wrote:
I've always asked (or automated asking <http://danger.systems>)
contributors to add CHANGELOG entries
<https://github.com/danger/danger-js/blob/master/changelog.md> from a
user's perspective. Trying to automate it from PRs and commits has never
worked for me as their audience is different (targeted at devs)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1047 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIFygRipsvWH-Njfm2J67cmxIiK_TbUks5r7aETgaJpZM4NeEj8>
.
|
|
Nice @orta , love the concept of Danger CI. That's really cool. I'm going to propose that we run with manual release summaries and edited PR titles:
The rationale is that policing things at the commit level is too much overhead, but moving forward we should be able to enforce sensibly-named PRs that are user-centric. It's an experiment, and we can fall back to the tried-and-true method of manually editing the CHANGELOG after a few releases if it doesn't prove out. |
|
Best practices for CHANGELOGS for anybody who's interested: http://keepachangelog.com/en/0.3.0/ |
|
@ndelangen i moved the CHANGELOG to the root. let me know if you think i should make a copy instead.
|
ndelangen
added
documentation
maintenance
# Conflicts: # HISTORY.md # ROADMAP.md
…6-3.0-release-notes
Codecov Report
@@ Coverage Diff @@
## master #1047 +/- ##
=======================================
Coverage 12.84% 12.84%
=======================================
Files 198 198
Lines 4540 4540
Branches 718 718
=======================================
Hits 583 583
Misses 3322 3322
Partials 635 635Continue to review full report at Codecov.
|
ndelangen
changed the title
Issue: #1046
What I did
Inspired by:
What I need
tagHow to test
Browse the formatted release notes HERE