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

Make it better #4

Open
knowbody opened this issue Apr 19, 2016 · 1 comment
Open

Make it better #4

knowbody opened this issue Apr 19, 2016 · 1 comment

Comments

@knowbody
Copy link
Owner

I'd love to make the RN release notes process painless. At the moment this script does a very basic and dummy classification (checks for some keywords, either related to the platform or to check if the commit is bug, feature or other).

All that is not clever and only helps with the initial draft of the markdown file, but it saves some time already.

The bad parts

  1. uses Github API which returns max 250 commits (very often there are more commits in a release)
  2. very basic classification, (checks only the title of the commit)
  3. use of Github API, makes the whole thing slow

Possible solutions

  • instead of using Github API, just make the script to clone the RN repo and then just using git commands: get branches, get commits (this will solve 1. and 3.)
  • classification:
    • there are some commits which we can be very easily assigned based on the commit title.
    • the commits which the script is not confident with, could be investigate more (check the files which are being changed, how big is the change, check not only the title but also the message of the commit)
@grabbou
Copy link

grabbou commented Apr 19, 2016

Thanks for the write up! Looks like our aim here is a bit ambitious, but who does not like doing crazy stuff in the free time.

Anyway, here's my current thinking - happy to hear your feedback and let's start!

I think we should switch from grouping by a commit message / details to group by a files touched. That prevents things when one commits Fix HMR to work as on Android from being wrongly classified.

I don't think we need to clone the Git repository since the user is probably going to have it already. I propose the main interface to be:

$ ./make-release-notes 0.25-stable...0.26-stable

so that they follow the diff view semantics here. All we would need to do here is to make sure one has all required branches and that they are up to date. That also makes it easy to move it to scripts folder in react-native repository in the future (hopefully!) when it gets more stable since it's going to be already following its patterns :)

In terms of grouping, I would prefer an object similar to the one below:

const settings = {
   ios: [],
   android: [],
   general: [],
   ignore: [],
};

that defines an array of regexp rules for each group that will make the file match it. If there are files matching both iOS and Android in a single commit - automatically classify it as a General and return early.

That would obviously require some extra work to specify all paths, but it gives us loads of possibilities, like:

  • classify as Android all .android.js files and all .js files from folders that contain Android in a name, e.g. DrawerAndroid.

So that is the first step.

Let's imagine the main interface to be:

type Commit = {} // to be discussed if an object or just SHA

type CommitPlatform = $Enum<typeof {
  Android: 'Android',
  IOS: 'iOS',
  General: 'General',
}>

type CommitType = $Enum<typeof {
  Feature: 'Feature',
  Bug: 'Bug',
  Deprecation: 'Deprecation',
}>

function filterOutSmallishCommits(): Array<Commit> {};

function groupByPlatform(commits: Array<Commit>): Map<CommitPlatform, Array<Commit>> {};

function groupByType(commits: Array<Commit>): Map<CommitType, Array<Commit>> {};

function getReleaseNotes() {
   const commits = groupByPlatform(filterOutSmallishCommits());
   return _.mapValues(commits, (list: Array<Commit>) => {
      return groupByType(list);
   });
}

Note The above flow type definitions 99% have some issues, but just demoing basic idea

The filterOutSmallishCommits codename step would just filter out all commits that touched less than a single line (likely typos) - however since that might change in the future - better to have it as a separate function.

The groupByType (3rd step) would take the return from groupByPlatform (described above), which essentially would be an array of commits grouped by platform (ios, android, general) and group them by feature, bug, deprecation.

I don't have an opinion how to group by severity yet, so for now - let's just assume it's a function that will return an array of commits grouped by platform and then, grouped by the type.

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

No branches or pull requests

2 participants