Breaking change flag to avoid old packages becoming broken (like NHibernate

Aug 20, 2011 at 11:17 AM
Edited Sep 22, 2011 at 7:49 PM

Edit: Removed the article, as it turns out I misunderstood - the issue was caused by Antlr 3.1/3.1.3 not being compatible. If the newer version had been package as 3.2, this wouldn't have been an issue, as apparently NuGet only fetches the latest version with the same/lowest major/minor version!

Aug 20, 2011 at 6:36 PM

As you learned, the version number is the compatibility flag.

However, you raise an interesting question. What happens when a package owner does it wrong? Could we crowdsource fixing the issue?

It's a tricky issue. As a package owner, would you want others changing the behavior of your package? Well, probably not, but it goes both ways. By uploading a poorly versioned package, you just changed the behavior of other packages in a negative way.

So I think in this case, it might be possible to do something about it.

Some Ideas:

1. A breaking change flag within Note that this would not be in the package itself. Ideally, package authors would properly version packages. This would allow folks to mark a package as a breaking change and upon review, we could mark it with this flag in the site and it would be treated as if it had an incremented minor version. That's a pretty big change though.

2. We allow rewriting the version of faulty packages. This is better than taking the package down entirely. The idea would be, when you report a breaking change, contact the owner. If they refuse to fix it, we increment the version number.

3. We mark the package as a pre-release package. This is a feature coming in the future, but it would prevent a lot of these issue if the breaking change package was forced to be treated as a pre-release until it was fixed.

Honestly, all of these ideas sound harsh. But so is breaking packages that work fine in the feed today.


Also, did you contact the Antlr package owner?

Aug 20, 2011 at 7:20 PM

This all sounds a little too complicated to me :) It's best to find ways to prevent authors from doing bad things in the first place with proper education. Hopefully most authors understand that having breaking changes between 3.1.0 and 3.1.1 is not good. And I don't think we've had many cases where this has happened, so I wouldn't call it a widespread issue.

Maybe one issue is that we don't make it easy enough to contact the owner. From the VS dialog, we have no easy path to the 'Contact Owner' page.

Aug 20, 2011 at 7:25 PM

@Phil Haack - Good point - I probably shouldn't have removed my post so hastily - despite the fault being with the Antlr package, the issues still exists and it's not obvious to users what's gone wrong, or how to fix it :o(

I think adding a breaking change flag is probably a little redundant given version numbers already do this. However, I think this will be very tricky to solve without some sort of "moderator" to look into issues. Users could "report compatibility" issue, but claims could be bogus, so it'd be risky to do anything without a trusted mod looking into it (especially if the package owner doesn't respond or rejects claims the package includes a breaking change).

@David Ebbo - I agree it could be easier to contact authors, but as times goes by, people will care less and less about fixing "old" packages, which is probably where we're most likely to see this. People may also stop contributing/"abandon" libraries, and it would be good if the community could fix things up if it happens.

We don't want to get into the situation where people start bundling other libraries into their own package to avoid any compatibility issues - that would be a mess :-(

Aug 20, 2011 at 7:28 PM

I sent a message to the Antlr project owner through the NuGet site explaining the issue, and included a link here. I don't know if re-versioning 3.1.3 to 3.2 will cause any issues with other packages. If they say they work with >= 3.1.3, would NuGet fail to find a valid version, or would it use 3.2?

Aug 20, 2011 at 11:11 PM

It would use 3.2.

Aug 21, 2011 at 2:34 AM

Check out my blog series for details on how NuGet deals with versioning. Generally, I think the algorithms have held up well, and we've only had issues when there are some clear versioning mistakes made by the author (as is the case here).

Aug 21, 2011 at 10:03 AM

@David Fowler - Of course, you said lowest Major/Minor, not exact. Seems like that will fix it for Antlr then.

If the Antlr owner is not responsive, I presume the NHibernate package owner could fix this but putting =3.1 in the package?

@David Ebbo - Not sure why those articles didn't appear in my feed reader - good stuff in there, but I hadn't seen them before (though I have had recent stuff, like your post on David Fowler's NuGetPowerTools) :(

Sep 22, 2011 at 7:34 PM

In the month since posting this, I've had no response to my email to the Antlr author, and the package is not fixed :-(

In this case it's probably not that important, since I don't think there are many people using such ancient versions of libraries, but I think it does highlight a potential problem with "uneducated" package authors unknowingly breaking dependant packages :o(

Sep 22, 2011 at 7:42 PM

For some reason, the Antlr package doesn't have a clear own in the gallery, so I'm not surprised that the contact form went nowhere. We need to get someone who actually works on Antlr to take ownership of it and clean things up. Maybe start with!/the_antlr_guy?

Sep 22, 2011 at 7:46 PM

The package has the name "Terence Parr" against it. I assume it was the person that created it as there are no other packages with this name, so it's unlikely to have been someone uploading it so they could use it as a dependancy?

Anyway, will try getting a response on Twitter!

Sep 22, 2011 at 7:59 PM

No, I think it was uploaded by a NuGet team member way way back in January. But looking at, I'm guessing that Terence Parr is!/the_antlr_guy :)

Sep 22, 2011 at 8:20 PM

Please contact him. What you’re probably seeing is the author field, which is a way to give credit to the original author, but is different from the owner. We’re working on improvements to the gallery to make that distinction more clear!

Sep 22, 2011 at 9:10 PM

is it "more clear" or "clearer"? I'm always confused about that :)

Sep 22, 2011 at 9:13 PM

Sep 23, 2011 at 7:21 AM

@DavidEbbo So it's your fault it doesn't work? ;-)

@Haacked He responded from Twitter, but said the package wasn't him. Is there any way to transfer it to him (if he wants) or even find the NuGet team member who created it so they can fix it? (Though this may cause issues for anyone referencing 3.1 expecting 3.1.3?)

@DotNetJunky ...

Sep 23, 2011 at 7:32 AM

Yes, tell him to create an account on and tell us his account name and we’ll make him an owner.

Sep 23, 2011 at 8:13 AM

@Danny: If he's not up to it, you're welcome to take ownership if you want to give the package some love. Better a surrogate owner than no owner at all! :)