Improve major/minor upgrade logic

[rarkins]

Currently we just look at the "latest" tag from npm. This should be improved/replaced by instead looking for both the latest minor or patch upgrade as well as major upgrade for each package, by checking the dependency's versions list.

[rarkins]

More on current implementation:

• If latest release is a minor upgrade, then the branch is named like upgrade/angular
• If latest release is a major upgrade, then the branch is named like upgrade/angular-major

In theory this could already result in two branches from the script both existing if a minor upgrade branch already existed first, however the minor one will be orphaned and updated versions ignored as soon as a major release is available. e.g. if a package continued to make bugfixes to 1.x even after 2.x is released, we would miss that.

[rarkins]

I think it would be useful to support both major and minor releases concurrently. For example above, not many could transition to angular 2.x as soon as it's released, and still want minor and patch upgrades for 1.x for as long as they're available.

[rarkins]

As discussed in #2, it seems best to support one branch/PR for every major version that exists for a dependency.

But we also may want to have an advanced feature - how can a user "ignore" a major upgrade indefinitely?

e.g. let's suppose I know I don't want to upgrade to angular 2.x for a long time. Can I close the PR that was created with me, and yet somehow:

• Not have it recreated every time angular 2.x gets a minor or patch update?
• Support angular 2.x minor/patch updates one day once I've eventually updated the project to 2.x?

First question: how can the script know to not create a PR for a major update I want to ignore?

There needs to be some state kept in GitHub. You could keep a branch around with a closed PR (something the script could detect), but having orphan/unwanted branches is nearly as bad as having the PRs. So let's say the user wants to close the PR and delete the branch. In that case the only state we have left is a closed PR.

According to our conventions, the closed PR would have been named something like "Upgrade angular to version 2.1.0" and pointed to a branch named upgrade/angular-2.x. The web interface of GitHub appears to remember that deleted branch name, although I'm not sure if the GitHub API gives that same info. Also, we couldn't know the exact PR title when it was deleted, so we'd have to search closed PR titles for a substring 'Upgrade to angular version 2'.

Assuming that's possible, we could have the logic "If it's a major upgrade, and a PR already existed for that major upgrade, then don't create a new branch/PR".

Later on, if the user manually creates their own branch/PR to upgrade angular to 2.x, then the script should catch the next minor upgrade of 2.x because the logic would return false for "If it's a major upgrade". So this seems like a feasible way to let users ignore major upgrades indefinitely but have the script wake up again to help with minor upgrades later.

[rarkins]

I think this issue can be broken into at least 2 parts:

1. Support minor and major upgrade branches concurrently
2. Support ignoring major upgrade branches/PRs if the user closed one previously