Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Changelog maintenance #47
I don't know if this discussion is right place, but there is no space where users and developers can read changelogs about patch versions of RN in friendly way.
Is there any way how to automatically generate changelog from release notes of cherry-picked commits?
So, couple things related to this:
well, that's not entirely true:
No, at the moment there is no automatic way to generate the changelog, and the effort to work on it (as I've pointed out on this discussion about the OSS RN cycle) is non trivial.
The reason that this Changelog.md file has not been updated with the "minor" versions changelog is simply because the person that had offered to help mostly with the changelog is currently not available.
I share your concern about the changelog not being as up-to-date as the code, and a couple days back I was literally talking about it with the Core - but I didn't have time yet to submit a PR with a new section per each of the two minors we have released for 0.57.
...but here's the catch - this is an OPEN SOURCE repo
You are right about it. But two weeks before i don't even know about react-native-releases and discussions-and-proposals repositories. For uninterested people on detailed development of RN it is invisible.
I see that React Native have different workflow about merging commits. In react they are merged naturally (purple icon about merging) it is "natural" way of Github. It looks like React Native do it in different way. Pull request is copied as commit and then original PR is closed (red icon).
With automated tools we could extract release changes from PR. Until when RN merging process will always closing PR instead merge, it is hard to make any automated tool.
I think appending Changelog.md for patch versions could be made manually yet. To show "best" changes and at the end put link to see all diffs between current and last patch version.
The changelog attempts to follow the Keep a Changelog 1.0.0 format. All releases should be entered, including patch releases. I've not been able to help as much recently, but I do plan to hop back in and help with this soon. There are some gaps in the document as well as the process that creates it.
Completely agree! Going through this pain with a project this week.
This is something that I'm constantly weighing. The changelog entry today starts by reviewing the merge commits and trying to classify them based off of keywords (a script helps with this -- it creates a draft changelog). From there, related merges are combined, and the themes emerge. Due to the shared nature of the project (both internal FB development and community development), there is no kanban or WBS that we can look to to inform the changelog; the commits and then follow up discussion really are it. There are some special cases like reverse merges and commits straight to master/release branch that need handling, too.
A few things top-of-mind for me to do:
@turnrye How valuable are the release notes that are part of PRs? It seems like there is still a bunch of manual work necessary after that.
What can we do to make that process easier in an automated way? I think we could consider revisiting enforcing something on the Facebook side if it would radically change the ability to create and maintain high quality changelogs.
@TheSavior They are incredibly helpful, but I don't know that reviewers always check for completion or accuracy. I'd like to suggest some changes to the template.
As for the work that syncs from FB internal, the messages on the merge commits can be inconsistent. Some are short and to the point while others are detailed with background and context. Then there are some that lack much detail at all; this is especially the case in bugfixes for recent changes (I don't have a good recent example). I think part of the breakdown here is that often times, there is information in internal FB systems referenced (like a D***).
I'd look for similar information in both sets of merge commits. I'm finishing collecting thoughts around this now, and I expect to share tomorrow afternoon.
Edit: Going to hopefully get things shared this weekend. Didn't have as much free time this afternoon as I expected.
I'm going to start by:
I'll take this PR dialog approach for a while (maybe two releases) and then assess if a process should be established and where a tool can help.
If you have a suggestion of how I can engage internal users on synced merge commits, I'd greatly appreciate it.
referenced this issue
Nov 4, 2018
@turnrye love your changes in template facebook/react-native@ce18036
@TheSavior reviewed #69 and there are many changes which are not interesting for end-user developers. For them, no fix, no change or no new feature is added in public API. They use same code as before. It is for internal usage, as adding comments, better type checking, renaming private functions, typo fixing, code style changes etc.
Something like removed