greenkeeperio
Support "ignore" as an object of semver ranges
Currently, I can specify:
"ignore": [
"foo",
"bar"
]
I'd like to do:
"ignore": {
"foo": ">= 3",
"bar": "^4"
}
The goal is to allow autoupdates of backports when a semver-major breaks me, so I can't update to it, but I don't want to just ignore it permanently. Separately, the semver range serves as documentation of exactly which version I wanted to start ignoring, making it easy to find out why.
(per https://twitter.com/janl/status/953889075764908033)
related: #434 and #521
tl;dr: while supporting ranges as external config would be a big an welcome improvement, i'd propose that greenkeeper instead honors the range defined in the package.json already.
with the change to update lockfiles for in-range updates, i think maintainers are now more able to define ranges directly in the package.json that could inform greenkeeper what is acceptable for that project. once the project is ready to accept versions beyond what they previously defined, they can adjust the range.
i'd propose that greenkeeper instead honors the range defined in the package.json already.
once the project is ready to accept versions beyond what they previously defined, they can adjust the range.
Half the reason for Greenkeeper is to be notified when a new version is published outside your allowed range, especially when you aren't watching the dependencies so you don't know when newer versions are available. I'm having trouble with understanding how you expect your version to work @travi.
The proposal outlined here marks it explicitly that you know there are newer versions available, but don't want Greenkeeper to tell you about it.
Indeed, if greenkeeper honored the range in your package.json it'd never provide semver-major updates.
I remember to have discussed this before. I think it’s a good idea, we came up with a different format if I recall correctly
"ignore": ["foo@>=3", "bar@^4"]
Either would work. the benefit of sticking with an array is that it will be easier to read if only some have a version range limitation, e.g.
"ignore": ["foo", "bar", "baz@>=3"]
Sure, that’s fine! Either format works. (In the object form, you’d simply do ”foo”: “*”)
the concern i have with this proposal beyond maintaining more than one definition of the acceptable version range for a dependency is the use of ignore for the way to define it.
since greenkeeper currently only sends PRs for versions that are published as latest, there are two changes being proposed:
- if the
latestversion is greater than the range defined inignoredo not send a PR to the project - if there is a version published that is lower than the range defined in
ignore, send a PR even if not released to thelatestchannel (LTS versions, etc).ignoreis a bit misleading for this case
if we move the definition of this to the config, i think it is important that you are really defining what to do with versions not published to latest in addition to just ignoring latest that are too new. if we think along those lines, i think we could extend the proposal to account for pre-releases as well. for example, if latest is 3.4.1 and 3.5.0 is published to the next channel, this type of config would enable opting into further releases to the next channel with something like foo@>=3.5
if the latest version is greater than the range defined in ignore do not send a PR to the project
This seems totally fine to start.
ignoreis a bit misleading for this case
I don't see how. The fact that it only looks at "latest" is an implementation detail, and is not implied in any way by "ignore".
Separately, the "latest" channel is only relevant for what you get from npm when you omit a specifier; I would expect that greenkeeper would watch for versions that are "latest" or that are <= "latest", regardless of channel.
I don't see how.
the way i've been thinking about it is that when you want to limit greenkeeper PRs to, for example, the v3 LTS releases after v4 has become latest, i dont think that specifying ignore would imply that you should start getting PRs for v3 versions. without specifying the ignore rule, greenkeeper would have been sending my project all of the v4 versions that were published since v4 became latest, but would not have sent me any of the v3 versions that were published as LTS since that same point. by then adding the ignore rule, i would expect to stop getting v4 PRs, but ignore doesnt imply that i would start getting the v3 releases again.
documentation could explain this away, but i dont think its intuitive by itself
good point, once bar@4 is released, I would no longer release [email protected] releases with the @latest dist-tag. And Greenkeeper currently ignores non-latest releases anyway. So practically a setting like "ignore": ["bar@>=4"] would have no effect, as Greenkeeper would not create branches for [email protected] releases any way, in its current form
Is that what you are referring to @travi?
I think what I’d expect is that gk sends me PRs for the latest published version I’m not ignoring.
@gr2m yeah thats what i mean. either way, we're proposing more change to the current greenkeeper behavior than just ignoring releases defined by the ignore config.
I think what I’d expect is that gk sends me PRs for the latest published version I’m not ignoring.
i agree that this is a reasonable assumption and the config acting that way wouldnt be wrong, but its not very explicit. it would also be potentially unexpected by those familiar with current greenkeeper behavior.
its also limiting, thought, because it assumes you would only want to ignore newer versions. if i wanted to opt-in to pre-releases on a channel like next, ignoring lower versions released on the latest channel
I would expect that greenkeeper would watch for versions that are "latest" or that are <= "latest", regardless of channel.
i can see the point here, but i think that is far riskier for pre-release channels than LTS channels. i would not want the default behavior of greenkeeper to be that my project gets the PRs for pre-release channels that i have not opted into. this is a big part of why channels exist and why it is so frustrating when a package maintainer accidentally publishes a pre-release to the latest channel (even temporarily since greenkeeper is so quick to send PRs).
since greenkeeper currently only sends PRs for releases to latest, do we need to consider channel more explicitly to accomplish all of what we've talked about? it seems like we need to tell greenkeeper which channels to watch, but then within that set of channels define the range(s) to ignore. maybe ignore does make sense if we approach it like that?
I mean, the default for every package name is "latest"; maybe instead, adding an "overrides" object that allows me to provide a custom semver string for greenkeeper to watch for? That way if I specified <= 3 it would override "latest", and when filtered on the entire list, would provide all the things that semver-satisfies that range?
ah, sure. i misunderstood the details of what you meant then.
i could see either approach working in that case. defining channels to watch with ignore rules within that pool might be less work on the greenkeeper side. however, if defaulting to latest and overriding with a semver range of acceptable versions instead of just latest, that should accomplish the same goal. i do like something along the lines of overrides better in that case than ignore, though.
not saying it’s better (or not), but being more explicit about what channel to subscribe to might be an alternative to adding sth like baz@>=3 to the ignore array.
So instead of
"ignore": ["foo", "bar", "baz@>=3"]
we could do
"ignore": ["foo", "bar"],
"subscribe": {
"baz": "lts"
}
where lts is the distribution channel that the baz project is using for their 3.x releases.
If I don’t want to receive 4.x releases once they get released using the lts distribution channel, we could either do
"ignore": ["foo", "bar", "baz@>=3"],
"subscribe": {
"baz": "lts"
}
or
"ignore": ["foo", "bar"],
"subscribe": {
"baz": {
"channel": "lts",
"version": "<4"
}
}
@gr2m is there a valid case for subscribing to more than one channel? the one that comes to mind for me is the case where i've opted-in to next releases and they eventually get promoted to latest. i would want to ignore v3 releases at that point regardless, but i would want v4 releases from next for now, but would still want them from latest once they start showing up there instead.
I think "channel" is the wrong idiom; they're "tags" in npm parlance, things can have multiple tags or none, and I'd want a way to subscribe all things to all versions.
Related discussion here: https://github.com/greenkeeperio/greenkeeper/issues/287
Hi all, I think this feature is a must-have in order to avoid "out-of-range" update that can't be merged (and get a notification flooding update).
Checking the code, the function to edit should be this one: https://github.com/greenkeeperio/greenkeeper/blob/a19e1e5d8b6e634424ebd0470a4bc393807e4a70/utils/initial-branch-utils.js#L72
right?
Is the correct/defined format this https://github.com/greenkeeperio/greenkeeper/issues/581#issuecomment-358788356 one?
