Nuget and NHibernate 4.0

[Oskar Berggren]

Does anyone know...

If we release NHibernate 4.x under the existing "NHibernate" Nuget
package name, containing binaries only for .Net 4.0, is the Nuget
client smart enough to suggest an update only for projects that
actually target .Net 4.0? Or will it try to update also projects that
target .Net 3.5?

/Oskar

[Diego Mijelshon]

This is just a guess... it'll probably try to update everything, but it might rollback when compatible dlls are not found in the package.

You can test this by creating a local package source (pointing to a folder where you drop the nupkg files)

Now, to answer your implicit question :-), we should NOT create a differently-named package for NH4. 4.0 is the currently stable .NET version, and projects using 3.5 are already in the maintenance stage, where people usually don't blindly update the libs.

/Oskar

--

---
You received this message because you are subscribed to the Google Groups "nhibernate-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nhibernate-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ramon Smits]

Nuget does not auto update stuff so it is safe to release a new package.

However, when other packages have a dependancy to NHibernate 3 and they didn't set the correct dependancy version then they will automatically update to the latest version instead of updating to the latest non breaking.

http://docs.nuget.org/docs/reference/versioning

So they should target like this: 

<dependency id="ExamplePackage" version="[3,4)" />

And not like:

<dependency id="ExamplePackage" version="3" />

or not specify a version at all.

-- Ramon

/Oskar

[Diego Mijelshon]

They should do that only if they determine they're not compatible with 4.0.

Otherwise, they'd be unnecessarily limiting their end users.

[Stephen Bohlen]

That's one of the very real problems (among many) with NuGet.  They want to base upgrade logic, etc. on "semantic versioning" rules but their 'default' interpretation of "=1.2.3" for the versions of dependencies is in contravention to those very rules :(

The meaning of semantic versioning is precisely that 3.x and 4.x are *explicitly* permitted to contain breaking changes.  But when you say your package depends on NH version "=3.1.1." you are in fact only stating "at least 3.1.1 and *anything* that might come after it".  Since its *impossible* for an author of a package that depends on the work of another to be able to really *ever* make that statement (predicting the future, as it were), it turns out that "=1.2.3" is almost NEVER the proper thing to use when declaring your dependencies.  But of course most package authors don't fully reason this through and mostly without realizing the implication quite happily state "=1.2.3" all over the place for their dependencies :(

The only way "=1.2.3" (meaning "1.2.3 or later") would be the right thing to say was if the meaning of "or later" only went as far as the *semantic versioning* rules permitted it to assume.  So in the case of "=1.2.3" the meaning would have to become "version 1.2.3 or later up to but NOT INCLUDING 2.0 or later" (since changing the first numeral is the 'break point' at which backward compatibility can no longer be assumed).  Unfortunately, this *isn't* the way nuget behaves when interpreting "=1.2.3" today and so the vast majority of existing packages are presently mostly broken in re: their statements of dependency versions :(

I infer that there are too many existing packages out there for NuGet to properly begin to respect semantic versioning rules re: updates at this late date and this is probably why the team has chosen to leave this (still) broken...

-Steve B.

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Ramon Smits]

That is why [1.2.3) does work. It should work dependancy wise. If the package maintainer later on decides that 2.* is also compatible then they should publish a new version of THEIR package with a minor version upgrade that includes [1.2.3,3) to mention that it is safe to update till version < 3.0

-- Ramon

[Ramon Smits]

That is the responsibility of the package maintainer to see if a new major version is still compatible. He SHOULD check for this and not allow this by default.

[Stephen Bohlen]

Right -- that's what I was suggesting is the 'correct' way to approach stating dependencies ... but since NuGet makes no bones about encouraging SymVer, IMO it would have been best if that exact version dependency syntax had been the initial *implied* meaning of "=1.2.3" rather than requiring the "=[1.2.3)" construct.

My evaluation of randomly-selected NuGet packages (that have additional dependencies, NH or otherwise) combined with my anecdotal review of my tweetstream, inbox, etc. when one of these dependencies is updated in NuGet suggests that very few package authors appreciate this distinction.  This makes authors of packages upon which others depend (such as ours) have to make a choice: play by the rules (and break lots of packages that don't play by the rules) or work around the rules (to not be 'blamed' unfairly for 'breaking' others' packages with our updates).

-Steve B.

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen