Renovate closed all PRs with unmerged commits, not creating new ones..

[soenneker]

How are you running Renovate?

A Mend.io-hosted app

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

No response

Please tell us more about your question or problem

All of the PRs that Renovate created closed yesterday with unmerged commits, and it's not opening new ones for libraries that are out of date. These are C#/NuGet solutions. Is there currently an outage?

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[jamietanna]

Are you able to share any Job ID(s) or a link to your repo?

I've seen one report about this before, so it's possible that a network issue may have led to Renovate seeing no-result ("no updates available") and so the PRs were closed

[jamietanna]

The main reason I was writing comments here after I was made aware of this discussion is because the other one is marked as answered.

A thread being "answered" doesn't mean it won't get future responses, more that we believe we've given the core answer needed - apologies if it felt that was us (my words) "shutting the door on you", Martin!

[jamietanna]

Hey folks, I've been OOO this last week, so catching up on this now.

To summarise, I believe we're discussing two separate - but related - concerns being discussed in this thread:

1. Renovate stopped updating a version number 1.2.3
   • This regression occurred in 43.208.2 (fix(worker/lookup): don't use a range as current version #43737), and was effectively reverted in 43.214.0 (feat(manager/nuget): default rangeStrategy to bump #43820)
2. Whether Renovate should update a version number [1.2.3]
   • This is a point of preference, not a bug

---

For 1, we appreciate that this was an accidentally introduced breaking change, and that it caused unintended impact to folks using Nuget. As we've noted, we've since reverted this, and so there should still be updates to the 1.2.3 version ranges.

I believe this has been corrected, but @martincostello can you confirm if you've resolved the issue you're seeing, where you weren't getting 1.2.3 updates?

We'll look at making sure that there's sufficient documentation to clarify this for existing users (if we've not already got coverage).

We realise there is some balance between being "technically correct", but maybe not as clear to folks who aren't aware of the nuance between 1.2.3 and [1.2.3], and following how other tools do it, which isn't following the documented way that Nuget versioning works - we'll almost always opt for abiding by the standard.

Regarding the "in the next major version", that's currently the plan - but it doesn't necessarily mean our next major version, and will be based on feedback, our own testing, and timelines may change etc etc :)

---

For 2, this is a bit more nuanced, and comes down to how Renovate is different from a regular package manager.

By contrast, if I write "Version="[1.0]"", I am intentionally expressing “do not move this.” That is the actual pinned form.
[...]
I understand why 1.0.0 might be treated as a range under NuGet restore semantics, but [1.0.0] seems different: it is the explicit opt-out mechanism for updates.

Renovate does not aim to assume that a pinned dependency means the user doesn't want it to be updated. If it did, this would mean Renovate very infrequently ever updating dependencies (by default), especially in ecosystems like Go where the version specified is always an exact version.

This is a question we've fielded before - and I'll look at getting something explicit in the docs - but generally Renovate is there to surface "here are all the versions you could update", not to cater to different folks' interpretations of what "should" happen

(There is nuance here - we aim to make Renovate as predictable as possible, but we have different use-cases than a package manager/IDE extension)

Do I understand it correctly that Renovate - prior to 43.208.2 - would not by default update [1.0.0] and since 43.214.0, this is now updated? If so, there may be something we can do to tweak this so a [1.0.0] version keeps rangeStrategy=auto.

As an example, we see Dependabot suggest a dependency update to [13.0.1], based on a repro from earlier in the thread, which implies it's not all of the widely used tools that treat it as an version that shouldn't be touched.

---

As an aside, I'd like to remind users to read the Renovate CLI project's Code of Conduct, and to familiarise themselves with the guidance we have for interacting with the project.

Also, to be very explicit - to the person who emailed the CEO of the company that owns Renovate, this is not something we're happy about. Please avoid that behaviour in the future.

[soenneker]

I don’t think it is fair to characterize this as “different folks’ interpretations of what should happen.” Respectfully, that framing feels dismissive of the actual .NET behavior being discussed.

You make a fair point that Dependabot does not respect that behavior, but I do not think Dependabot should be the standard Renovate is trying to match here. Dependabot’s shortcomings are one of the reasons many of us use Renovate in the first place.

There is related discussion here, and I think the community feedback is fairly clear:
dependabot/dependabot-core#11856

Renovate does not aim to assume that a pinned dependency means the user doesn't want it to be updated. If it did, this would mean Renovate very infrequently ever updating dependencies (by default)

That may be true in other ecosystems, but I do not think it applies 1:1 to .NET.

1.0.0 is the default format used when installing a package and I still stand by my view that it's effectively a pinned version during package management because there are many situations where treating it like a simple range doesn't work (compilation, runtime conflicts, etc). Again .NET package management and NuGet restore are different things. 1.0.0 still attempts to use that exact version, it just allows -some- flexibility in the dependency graph. That is precisely why mainstream .NET tooling treats [1.0.0] differently from 1.0.0.

Do I understand it correctly that Renovate - prior to 43.208.2 - would not by default update [1.0.0] and since 43.214.0, this is now updated? If so, there may be something we can do to tweak this so a [1.0.0] version keeps rangeStrategy=auto.

Yes, that is correct.

Also, to be very explicit - to the person who emailed the CEO of the company that owns Renovate, this is not something we're happy about. Please avoid that behaviour in the future.

That was me. Since this was raised publicly rather than addressed to me directly, I’ll respond publicly as well.

I find it surprising that a concern about my escalation path was handled by publicly calling out an unnamed person in the thread. I do not think that was the right way to handle it either.

I escalated because this did not feel like a normal technical disagreement.

Some examples:

No. Renovate will suggest updated for pinned updates that's literally the tool's job. I don't get what you want from the tool

It was explained quite extensively prior, and there were no follow up questions.

Done & merged. Please retry with the latest version and report any problems that you find.

But the issue being discussed was not actually resolved. The immediate bump behavior was fixed, yes, but the underlying question about exact NuGet version constraints was still being discussed.

Does this mean exact pinned versions like [1.0] will no longer be updated by default? I don’t see a new PR covering that.

Please create a reproduction.

It was later clarified that the reproduction request was so I could understand the behavior myself, not because the behavior was unclear. That is exactly the problem: I asked for a direct answer on intended product behavior and was instead treated as though I simply did not understand what was happening.

From my perspective, the underlying questions only started being addressed more directly after I escalated.

You can be unhappy about that escalation. I understand that. But I do not think it is accurate to frame this as though Renovate handled the communication well, listened consistently, or was uniformly constructive throughout the thread.

[soenneker]

Code of conduct:

Do not give a thumbs-down emoji to posts. Even if you are sad, or angry about a response: do not use the thumbs-down emoji.

The only time a thumbs-down is appropriate is when we, or a user, asks for a vote about something.

I'd also like to remind the maintainers and contributers to read the Renovate CLI project's Code of Conduct, and to familiarise themselves with the guidance for interacting with the project.

[martincostello]

A thread being "answered" doesn't mean it won't get future responses, more that we believe we've given the core answer needed - apologies if it felt that was us (my words) "shutting the door on you", Martin!

Some projects frown upon comments on answered/resolved discussions/issues ("Please open a new issue"), plus it wasn't getting any input from anyone from renovate, which I why I moved to the other thread. No motives assumed, I just wanted my comments seen and replied to (which has happened).

I believe this has been corrected, but @martincostello can you confirm if you've resolved the issue you're seeing, where you weren't getting 1.2.3 updates?

The main issue for me was that my solution for pinning was broken. It turns out that was because I was unintentionally using a glob rather than a regex, but that happened to work previously so the configuration I had happened to still work before. Once I made it explicitly a regex (martincostello/renovate-config#197) I get the old behaviour I wanted. I think had to replicate this fix in a few projects as I'd used the approach in other orgs. Also at the time of writing the fix hadn't been deployed to hosted renovate.

I would still agree there's a disjoint here for how NuGet versions work in practice for projects, and that the "don't suggest upgrades" behaviour isn't correct. 1.2.3 is the same as [1.2.3,) as far as NuGet is concerned, but this is for the purposes of restoring the dependency graph so that transient dependencies don't insist on a specific pinned version (like with [1.2.3]). Accordingly, I would expect renovate to create a PR for a bump from 1.2.3 to 1.2.4 for a dependency that is explicitly defined in a project. Users aren't going to get a newer version unless the dependency is already declared transitively in their graph, and a the dependency gets upgraded through such a transient reference. Even in a major version of renovate, that behaviour shouldn't return as I don't believe it's not functionally correct for .NET (distinct from NuGet).

[github-actions[bot]]

Hi there,

This is intended as a polite, automated request that users avoid @ mentioning repository maintainers like @viceice. Doing so causes annoying mobile notifications and makes it harder to maintain this repository.

We know it might be common elsewhere but we participate in hundreds of discussions a week and would need to turn off GitHub mobile notifications if we were mentioned in every one.

As a general rule, we will read and respond to all discussions in this repository, so there is no need to mention us.

Thanks, the Renovate team