Comments (4)
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.
from renovate.
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.
from renovate.
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.
from renovate.
I think this issue can be broken into at least 2 parts:
- Support minor and major upgrade branches concurrently
- Support ignoring major upgrade branches/PRs if the user closed one previously
from renovate.
Related Issues (20)
- Gitea: set `update_at` field when updating issues HOT 11
- Refactor config file detection/reading
- Invalid comparator in poetry (`!=3.0.`) HOT 6
- jsDelivr datasource
- Detect JsDelivr links in html manager
- poetry: `^1.2.3.0` (caret with four components) are not detected HOT 2
- Conflict in choosing the manager to process lockfile when multiple managers are using the same package file HOT 16
- Line breaks in K8s YAML files lead to missing update detection HOT 1
- hostRules.headers cannot be configured in config.js
- Support updateType=prerelease HOT 3
- Intelligent compatibility settings for Docker tags
- Formalize PR state storage HOT 3
- Clean up repo http cache after each run
- Cache http responses for same org HOT 1
- Save repo cache even if dry run HOT 3
- Measure package cache hit percent
- Cache public github tags/releases HOT 2
- PackageRules: add DepNamePrefix matcher
- Convert getRepoForceRebase to a per-branch setting HOT 2
- [Gitea] implement getBranchForceRebase
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from renovate.