What version is NHibernate at?

[pvginkel]

NuGet has its first 3.2.0 release at April 11th, but sourceforge is
still at CR1. Are the releases on NuGet beta/CR releases or is
sourceforge out of date with NuGet?

[Mohamed Meligy]

Not sure about CR, but...
When NH 3.2 is final, I expect it to be versioned 3.2.4000, similar to previous version schemes.

The current version in NuGet is 3.2.3001, which is released on the same day as NHibernate 3.2 CR1 in sourceforge (July 4th).
Based on that, I assume they are the same thing.

Check:
http://nuget.org/List/Packages/NHibernate/3.2.0.3001
http://sourceforge.net/projects/nhibernate/files/NHibernate/3.2.0CR1/ (note the date of the file)


Regards,

Mohamed Meligy
Readify | Senior Developer

M:+61 451 835006 | W: readify.net

    

--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

[sbohlen]

They are indeed the same thing as Mohamed suggests.  Disappointingly, NuGet (still) offers no formal mechanism for distinguishing pre-release "use at your own risk" packages from released "expect to be stable/reliable" packages and so teams are stuck following often discordant and poorly documented conventions for versioning to convey this information.

FWIW, the more people that raise (and vote for) the NuGet team resolving this process shortcoming in the NuGet ecosystem, the more likely that they will consider acting to address it so we'd encourage you (and others!) to visit http://nuget.codeplex.com and submit/vote/escalate this issue.

-Steve B.

[pvginkel]

Thanks. I figures as much.

Wouldn't it be an idea to create a separate package, e.g.
NHibernate.Beta and NHibernate.Castle.Beta as a "beta" channel?

> visithttp://nuget.codeplex.comand submit/vote/escalate this issue.
>
> -Steve B.

[sbohlen]

Sort of, yes, but the trouble with that approach is that there is no semantic correlation between such a 'beta' package and the (eventual) actual release, so that to 'switch' to the eventual release would require actually removing the attached beta package(s) and adding the newly-released version.  Not only is this invasive, but the NuGet infrastructure is unable to tell you that your attached beta package has finally 'gone release' meaning that the choice "update to latest version" in NuGet won't of course find the release.

What's really needed is...

• a flag in the package to indicate release version vs. pre-release
• the ability to specify in NuGet whether you want your referenced version to be narrowly-scoped to only take into account release versions or more broadly-scoped to include all pre-release versions as well when NuGet does its version-checking
  

Unless/until this concept of release vs pre-release package becomes a first-class, fully-integrated concept in NuGet (and its related tooling/ecosystem) any one of the possible work-arounds (the one you suggest, the one we've chosen, or a third, fourth , fifth, etc. idea) will represent some set compromises with some pros and other cons :(

We've chosen the present approach because it most-easily supports working within the present NuGet infrastructure to auto-update-to-latest when the final release version is available, but there are (of course) a multitude of possible "work-arounds" to handling this.

FWIW, this is actually a broader problem than just 'release' vs. 'pre-release' and extends to 'debug' vs. 'release' -built binaries as well (with their accompanying PDBs, etc.).  NuGet's present assumption that "all packages are created equal in all cases" is sadly naive and doesn't really represent all the use-cases that are really needed to be supported by a robust package manager.  Over time, we have to hope that these shortcomings will be addressed by the NuGet team, making NuGet more useful for both package authors and package consumers.

-Steve B.

[Fabio Maulo]

Problem solved.

NH3.2.0GA was released.

btw, pvginkel, in NH there isn't a so big difference between a Beta and the GA... in general the GA has more tests passing than a beta but the GA of 3.2.0 will have less tests passing than 3.2.1Alpha1.... and we currently have more than 4300 tests.
In practice a release is only something to allay people.

[David Mukaiwa]

+1 for the distinction feature of Nuget. Again, as Fabio says, the GA tag usually gtes you little more than peace of mind. Once the NH guys release code into the wild, you can consider it prettty much good to go.

--

You received this message because you are subscribed to the Google Groups "nhusers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/1Ekq9LfbwzAJ.