nuget version problem

Mar 14, 2011 at 10:10 PM

I've a nuspec as follows:

<?xml version="1.0" encoding="utf-8"?> 
<package> 
  <metadata> 
    <id>Jose.SessionPerRequest.NHibernate</id> 
    <version>1.0.3</version> 
    <authors>Jose Romaniello</authors>
    <dependencies>
        <dependency id="NHibernate" version="[3.0.0, 4.0.0]" />
    </dependencies>
    <description>
        Light implementation of the session-per-request pattern for NHibernate. Created by Jose F. Romaniello (@jfroma).
    </description> 
    <language>en-US</language>
    <licenseUrl>http://www.opensource.org/licenses/mit-license.php</licenseUrl>
    <projectUrl>http://jfromaniello.blogspot.com/</projectUrl>
  </metadata> 
</package>

and the output is:

 

 

PM> Install-Package Jose.SessionPerRequest.NHibernate
'NHibernate (≥ 3.0.0 && ≤ 4.0.0)' not installed. Attempting to retrieve dependency from source...
Done.
'Iesi.Collections  (≥ 1.0.1)' not installed. Attempting to retrieve dependency from source...
Done.
'Antlr (&#8805; 3.1.3.42154)' not installed. Attempting to retrieve dependency from source...
Done.
'Castle.Core (&#8805; 2.5.1)' not installed. Attempting to retrieve dependency from source...
Done.
Successfully installed 'Iesi.Collections 1.0.1'.
Successfully installed 'Antlr 3.1.3.42154'.
Successfully installed 'Castle.Core 2.5.2'.
Successfully installed 'NHibernate 3.0.0.4000'.
Successfully installed 'Jose.SessionPerRequest.NHibernate 1.0.3'.
Successfully added 'Iesi.Collections 1.0.1' to ConsoleApplication5.
Successfully added 'Antlr 3.1.3.42154' to ConsoleApplication5.
Successfully added 'Castle.Core 2.5.2' to ConsoleApplication5.
Successfully added 'NHibernate 3.0.0.4000' to ConsoleApplication5.
Successfully added 'Jose.SessionPerRequest.NHibernate 1.0.3' to ConsoleApplication5.

 

Why nuget install NHibernate 3.0.0.4000 instead of 3.1.0.4000? 

Mar 14, 2011 at 10:16 PM
I just repro-ed with all three methods of getting packages. Version 1.1.229.160 in visual studio.

NuGet.exe 1.3.20314.166
Mar 14, 2011 at 10:18 PM

ok, I'll open a new issue.

Mar 14, 2011 at 10:27 PM

This is by design. See my post on how the algorithm works. You should specify your dependency as simply: version="3.1"

Mar 14, 2011 at 10:31 PM

This package is compatible with 3.X.X.X, which should be the value on the dependency node?

Mar 14, 2011 at 10:34 PM
Ah. I keep forgetting what we settled on for the algorithm.

In the case where someone wants the latest version, is there anything they can add?
Mar 14, 2011 at 10:39 PM

'someone' being the package author, or the end user?

  • Package Author: just set the one you want as the min version, e.g. version="3.1". There is just no reason to set the min bound to 3.0 if you want 3.1.
  • End user: update-package
Mar 14, 2011 at 10:42 PM
Author intention.

I write a packgage and I don't want to have to update it, but I want someone to always get the latest and greatest in a known version area.

Is there a way to do this besides using an install.ps1 after it runs to update packages?

Mar 14, 2011 at 10:43 PM

Well.. 3.1 is between 3.0 and 4.0, 

What is the purpose of ranges?

http://nuget.codeplex.com/wikipage?title=Version%20Range%20Specification

Mar 14, 2011 at 10:46 PM

ehm...

the documentation say: [1.0,2.0] mean 1.0 <= x <= 2.0

My question is:

is 3.1.0 greater than 3.0.0 and less than 4.0.0 ?

Mar 14, 2011 at 10:46 PM

The point I make in my post is that this is sort of a fallacy, because you don't know up to what version you'll be compatible with until those versions come out. And there are some very valid reasons not to specify an upper bound initially, as that causes update hell later on (again, see my post :))

Mar 14, 2011 at 10:48 PM
Edited Mar 14, 2011 at 10:49 PM

@fabio, @jfromaniello: all this is covered in my post, and I really suggest reading through it first, as this is discussed in details.

Mar 14, 2011 at 10:53 PM

Perhaps this should be in the wiki (or at least a link to your blog posts)...

Mar 14, 2011 at 10:58 PM

Good point! I just added a Guidance section pointing to the posts.

Mar 14, 2011 at 11:02 PM

If I have published a code-only package having 99.99% to be compatible for any NH version since 1.2.0, can I simply write:

<dependency id="NHibernate" version="1.2.0" />
or I should re-push the package for each NH new version ?

Mar 14, 2011 at 11:11 PM
I understand your point, and i read all your post. I kindly disagree.
Here is my scanrio, my package is a code only package and rely on some
prety primitives interface that hadnt change since version 1.2 of
NHibernate and will not change.

And i though this was one of the advantages of releasing source.

2011/3/14, davidebbo <notifications@codeplex.com>:
> From: davidebbo
>
> Good point! I just added a Guidance section pointing to the posts.
>
>

--
Enviado desde mi dispositivo móvil
Mar 14, 2011 at 11:20 PM

This is not a scenario we have run into before, but if needed we might need to add support for it (please file tracking Issue). For most scenarios, the current behavior works best, as always getting the very latest would just cause too many breaks as incompatible versions become available.

For now, your best bet is to specify "1.2" and change it as needed (though it will auto-update to any hight 1.2.x).

Mar 14, 2011 at 11:22 PM

David, I read your post but there is something unclear.

If, in my package, I wrote version="3" mean that I'm aware the "3" mean "3.X.X.X"; I'm the owner of the package and I'm sure that my package is and will be compatible with any 3.x.x.x.

Why you have to choose the lowest ?

(the same is applicable for "3.1" and for the [3.0.0,4.0.0] )

How much intuitive is "update-package" for the end user ?

Using ranges how I can instruct NuGet to install the last available package of a dependency ?

 

Note: perhaps, so far, the focus is on DLLs dependency bat code-only-packages is a very very powerful NuGet's feature.

Mar 14, 2011 at 11:30 PM
Edited Mar 14, 2011 at 11:30 PM

Let's try not to confuse two discussions here:

  1. Making sure we all understanding the current behavior
  2. Suggesting possible future improvements

For #1, note that "3" does not mean 3.X.X.X. It means >= 3.

For #2, I agree we should look at supporting scenarios where you always want to latest in the range, and we should get that on the list.

Mar 14, 2011 at 11:37 PM
OTOH when you say "by design" , how many projects have you analized to
take such design decision? What projects?

Ndepend team has really interesting reports about breacking changes in
nhibernate.

Dont get me wrong, we want to help the nuget project to take the .net
framework to the next level. We believe it has a really good
potencial. But you will need to take more seriously our opinions,
because we (oss developers) have suffered the abscence of a good
package manager.

2011/3/14, José F. Romaniello <jfromaniello@gmail.com>:
> I understand your point, and i read all your post. I kindly disagree.
> Here is my scanrio, my package is a code only package and rely on some
> prety primitives interface that hadnt change since version 1.2 of
> NHibernate and will not change.
>
> And i though this was one of the advantages of releasing source.
>
> 2011/3/14, davidebbo <notifications@codeplex.com>:
>> From: davidebbo
>>
>> Good point! I just added a Guidance section pointing to the posts.
>>
>>
>
> --
> Enviado desde mi dispositivo móvil
>

--
Enviado desde mi dispositivo móvil
Mar 14, 2011 at 11:41 PM
+1 on being able to say "get latest".

how about a plus suffix to denote that you want the latest instead of the lowest? "3.0.0.0+" and "3.0.0.0-4.0.0.0+"

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471


On Mon, Mar 14, 2011 at 19:37, jfromaniello <notifications@codeplex.com> wrote:

From: jfromaniello

OTOH when you say "by design" , how many projects have you analized to
take such design decision? What projects?

Ndepend team has really interesting reports about breacking changes in
nhibernate.

Dont get me wrong, we want to help the nuget project to take the .net
framework to the next level. We believe it has a really good
potencial. But you will need to take more seriously our opinions,
because we (oss developers) have suffered the abscence of a good
package manager.

2011/3/14, José F. Romaniello <jfromaniello@gmail.com>:

> I understand your point, and i read all your post. I kindly disagree.
> Here is my scanrio, my package is a code only package and rely on some
> prety primitives interface that hadnt change since version 1.2 of
> NHibernate and will not change.
>
> And i though this was one of the advantages of releasing source.
>
> 2011/3/14, davidebbo <notifications@codeplex.com>:
>> From: davidebbo
>>
>> Good point! I just added a Guidance section pointing to the posts.
>>
>>
>
> --
> Enviado desde mi dispositivo móvil
>

--
Enviado desde mi dispositivo móvil

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Mar 14, 2011 at 11:43 PM

@David

for #1: there should be a way to mean "all 3 series"

for #2: Ok

Mar 14, 2011 at 11:43 PM

@David

for #1: there should be a way to mean "all 3 series"

for #2: Ok

Mar 14, 2011 at 11:45 PM
fabiomaulo wrote:

@David

for #1: there should be a way to mean "all 3 series"

There is, it's [2.0,3.0)

Mar 14, 2011 at 11:50 PM

mmmmmm...

I said all 3 series >>> 3.*.*.*

You syntax seems : 2.0<= x < 3.0

It not include 3.1 nor 3.2.....

Coordinator
Mar 14, 2011 at 11:53 PM

Fabio, it was an off-by-one error. :)

[3.0,4.0)

Mar 14, 2011 at 11:53 PM

Sorry, was off by 1. Obviously, I meant [3.0,4.0)

Mar 15, 2011 at 12:40 AM

Daniel's suggestion to add a + at the end to convey that behavior is something we can look into, but we'll want to carefully design this. The situation is:

  • NuGet 1.1 is the current public build
  • NuGet 1.2 is hopefully less than 10 days from release. At this point we're not making any big changes to it, so that would be too big a change
  • NuGet 1.3 could see such change. 

However, we could consider a small scope change in 1.2 that may just be good enough for many of those scenarios: completely omitting the dependency version could have the semantic of getting the very latest available (interestingly, we used to have that behavior is really early builds). This would cover the scenario above where you don't have an upper bound at all. Note that the lack of lower bound is mostly irrelevant, since we know the feed has the higher version that you need, so you'll never end up with anything less than you need.

Then in 1.3 we can consider bigger changes.

Thoughts?

Mar 15, 2011 at 12:43 AM
+1 IMO it is the best solution.

2011/3/14, davidebbo <notifications@codeplex.com>:
> From: davidebbo
>
> Daniel's suggestion to add a + at the end to convey that behavior is
> something we can look into, but we'll want to carefully design this. The
> situation is:NuGet 1.1 is the current public buildNuGet 1.2 is hopefully
> less than 10 days from release. At this point we're not making any big
> changes to it, so that would be too big a changeNuGet 1.3 could see such
> change. However, we could consider a small scope change in 1.2 that may just
> be good enough for many of those scenarios: completely omitting the
> dependency version could have the semantic of getting the very latest
> available (interestingly, we used to have that behavior is really early
> builds). This would cover the scenario above where you don't have an upper
> bound at all. Note that the lack of lower bound is mostly irrelevant, since
> we know the feed has the higher version that you need, so you'll never end
> up with anything less than you need.Then in 1.3 we can consider bigger
> changes.Thoughts?
>
>

--
Enviado desde mi dispositivo móvil
Mar 15, 2011 at 12:56 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.