Versioning - stable, unstable

Sep 10, 2010 at 9:16 AM

There is the notion of versioning 1.0, 1.2.34.5, etc. In addition to that, there is the notion of stable / unstable.

A common example, I may want to run on NHibernate 3.x unstable (which is essentially a daily build) or stick with the NHibernate 3.0 stable (tested release).

One way of doing that is to run this in a separate feed, but I think that this is something that is more likely to require a single feed.

I am thinking about the nupack.codeplex.com feed (or whatever the master one will be), and publishing daily build results there. I wouldn't want people to subscribe to a different feed just to get that.

I am thinking either something like:

  • nhibernate -unstable -ver 3.0
  • nhibernate.unstable -ver 3.0

Ideas?

Developer
Sep 10, 2010 at 9:25 AM

Right now the most significant properties on packages are id and version. The same package id has to be used in order to get updates. What you can do today is what you specify in your second bulleti.e. have a package whose id is nhibhernate.unstable and never change that id but change the version associated with that name (if you want to enable updates). That way people can do:

Add-Package nhibernate.unstable -> gets the latest daily build
Add-Package nhibernate.unstable -Version 1.4.5 -> gets a specific version

Add-Package nhibernate -> gets the latest "blessed" version of nhibernate

etc.

Does that make sense?

Sep 10, 2010 at 12:50 PM

Semantic versioning (semver.org) which has been discussed would accomodate this.

  • nhibernate -ver 3.0-unstable
  • nhibernate -ver 3.0.0.3-unstable
Sep 10, 2010 at 12:51 PM
How do I run on the current unstable, assume that I want to do something like:
Update-Package nhibernate


On Fri, Sep 10, 2010 at 3:50 PM, bsimser <notifications@codeplex.com> wrote:

From: bsimser

Semantic versioning (semver.org) which has been discussed would accomodate this.

  • nhibernate -ver 3.0-unstable
  • nhibernate -ver 3.0.0.3-unstable

Read the full discussion online.

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

To start a new discussion for this project, email nupack@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


Sep 10, 2010 at 1:00 PM

I don't think the cmdlet supports this (yet) but I see it as:

  • Add-Package nhibernate -ver 3.0-unstable
  • Update-Package nhibernate

The packages.xml holds the version of the package pulled down (or should) and where to get it (feature request I added but haven't implemented it yet).

I think the trick will be how to know the difference between an unstable version and the stable one. What if I want to advance the unstable one (basically a branch) so that:

  1. Push 3.0-unstable
  2. People grab it and use it
  3. Team pushes 3.1
  4. Push 3.0.1-unstable

Now how do people with 3.0-unstable get 3.0.1-unstable and not get 3.1?

I think gem solves this with the --pre flag. You can use semver so that you push 3.1 then push 3.2-beta which can be fetched using "gem install nhibernate --pre". You can keep updating the --pre version and as long as you use the --pre flag you'll get it. Then you push 3.2. The semver is there so you don't have to do silly stuff like 3.1.01, 3.1.02, etc. You just use the release version you intend to (3.2) and gem sees 3.2-beta as earlier than 3.2.

Not sure how much of this makes sense. Need coffee. Should just code.

 

 

Sep 10, 2010 at 1:06 PM

Need coffee... nice. The pre tag makes sense. I think this thread is aligned with the thread on pushing prereleases/betas. I was also thinking this could be a vNext feature.

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

On Sep 10, 2010 8:00 AM, "bsimser" <notifications@codeplex.com> wrote:
> From: bsimser
>
> I don't think the cmdlet supports this (yet) but I see it as:Add-Package nhibernate -ver 3.0-unstableUpdate-Package nhibernateThe packages.xml holds the version of the package pulled down (or should) and where to get it (feature request I added but haven't implemented it yet).I think the trick will be how to know the difference between an unstable version and the stable one. What if I want to advance the unstable one (basically a branch) so that:Push 3.0-unstablePeople grab it and use itTeam pushes 3.1Push 3.0.1-unstableNow how do people with 3.0-unstable get 3.0.1-unstable and not get 3.1?I think gem solves this with the --pre flag. You can use semver so that you push 3.1 then push 3.2-beta which can be fetched using "gem install nhibernate --pre". You can keep updating the --pre version and as long as you use the --pre flag you'll get it. Then you push 3.2. The semver is there so you don't have to do silly stuff like 3.1.01, 3.1.02, etc. You just use the release version you intend to (3.2) and gem sees 3.2-beta as earlier than 3.2.Not sure how much of this makes sense. Need coffee. Should just code.
>
>

Sep 10, 2010 at 1:55 PM
for semver the check is that there is an 'alpha' after the last number so

YES
1.2.3beta

NO
1.2.3-beta


-d

On Fri, Sep 10, 2010 at 8:06 AM, ferventcoder <notifications@codeplex.com> wrote:

From: ferventcoder

Need coffee... nice. The pre tag makes sense. I think this thread is aligned with the thread on pushing prereleases/betas. I was also thinking this could be a vNext feature.

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

On Sep 10, 2010 8:00 AM, "bsimser" <notifications@codeplex.com> wrote:
> From: bsimser
>
> I don't think the cmdlet supports this (yet) but I see it as:Add-Package nhibernate -ver 3.0-unstableUpdate-Package nhibernateThe packages.xml holds the version of the package pulled down (or should) and where to get it (feature request I added but haven't implemented it yet).I think the trick will be how to know the difference between an unstable version and the stable one. What if I want to advance the unstable one (basically a branch) so that:Push 3.0-unstablePeople grab it and use itTeam pushes 3.1Push 3.0.1-unstableNow how do people with 3.0-unstable get 3.0.1-unstable and not get 3.1?I think gem solves this with the --pre flag. You can use semver so that you push 3.1 then push 3.2-beta which can be fetched using "gem install nhibernate --pre". You can keep updating the --pre version and as long as you use the --pre flag you'll get it. Then you push 3.2. The semver is there so you don't have to do silly stuff like 3.1.01, 3.1.02, etc. You just use the release version you intend to (3.2) and gem sees 3.2-beta as earlier than 3.2.Not sure how much of this makes sense. Need coffee. Should just code.
>
>

Read the full discussion online.

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

To start a new discussion for this project, email nupack@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


Developer
Sep 10, 2010 at 5:06 PM

It feels like we're over thinking things, we can have a simple convention and correct me if I'm wrong but why would we need a --pre or --beta or --unstable flag? Isn't that the same as having a different package id?

Add-Package nhibernate-daily -Version 1.2.3

Am I missing something? 

Sep 10, 2010 at 6:01 PM
the --pre tag has been awesome in gems

people that want to run on stable just say

gem install rails

people who want to run with scissors can say
gem install rails --pre

the problem with a different package id is that you have to know the other name, and I would prefer to just say

Add-Package nhibernate
and
Add-Package nhibernate -pre


Its also nice because its an existing convention that people will already know, and don't have to know.

-d


On Fri, Sep 10, 2010 at 12:06 PM, dfowler <notifications@codeplex.com> wrote:

From: dfowler

It feels like we're over thinking things, we can have a simple convention and correct me if I'm wrong but why would we need a --pre or --beta or --unstable flag? Isn't that the same as having a different package id?

Add-Package nhibernate-daily -Version 1.2.3

Am I missing something? 

Read the full discussion online.

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

To start a new discussion for this project, email nupack@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


Sep 10, 2010 at 6:01 PM
it also prevents people who don't know better from accidentally downloading a beta

-d

On Fri, Sep 10, 2010 at 1:01 PM, Dru Sellers <dru@drusellers.com> wrote:
the --pre tag has been awesome in gems

people that want to run on stable just say

gem install rails

people who want to run with scissors can say
gem install rails --pre

the problem with a different package id is that you have to know the other name, and I would prefer to just say

Add-Package nhibernate
and
Add-Package nhibernate -pre


Its also nice because its an existing convention that people will already know, and don't have to know.

-d



On Fri, Sep 10, 2010 at 12:06 PM, dfowler <notifications@codeplex.com> wrote:

From: dfowler

It feels like we're over thinking things, we can have a simple convention and correct me if I'm wrong but why would we need a --pre or --beta or --unstable flag? Isn't that the same as having a different package id?

Add-Package nhibernate-daily -Version 1.2.3

Am I missing something? 

Read the full discussion online.

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

To start a new discussion for this project, email nupack@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



Sep 10, 2010 at 6:07 PM

Using -pre also has the benefit of keeping things consistent across packages, and it's a convention many folks will already know (from gems). And, if someone really wanted to differentiate with the package ID, they could (though hopefully for something semantically different than -pre).

Developer
Sep 10, 2010 at 6:23 PM
I think it's fine to take notes from gems but at the same time there is no package manager in .net today so you can't assume that there is even a convention that people know(every .net dev hasn't played with gems). We can come up with our own conventions that makes sense for .net packages, whatever that is.
Sep 10, 2010 at 6:27 PM

@dfowler Yeah, but a consistent way to take (unstable|edge|prelease) packages seems to have value, gems priori or no. :) 

Sep 10, 2010 at 7:00 PM
While some .net developers may not know the convention, its one that has already proved its usefulness in the ruby community, and rather than reinventing the wheel I would rather we take there lead, as well as adopting the SemVer style triggering of the -pre switch.

-d

On Fri, Sep 10, 2010 at 1:23 PM, dfowler <notifications@codeplex.com> wrote:

From: dfowler

I think it's fine to take notes from gems but at the same time there is no package manager in .net today so you can't assume that there is even a convention that people know(every .net dev hasn't played with gems). We can come up with our own conventions that makes sense for .net packages, whatever that is.

Sep 10, 2010 at 7:38 PM

I agree that there is value to having a clear way of choosing what 'channel' you want to install for a package (e.g. Stable/Beta/Daily).  We can't just rely on everyone (authors & users) just following a naming convention.

Sep 10, 2010 at 7:40 PM
why not?
the ruby group has been doing it with great success

-d

On Fri, Sep 10, 2010 at 2:38 PM, davidebb <notifications@codeplex.com> wrote:

From: davidebb

I agree that there is value to having a clear way of choosing what 'channel' you want to install for a package (e.g. Stable/Beta/Daily).  We can't just rely on everyone (authors & users) just following a naming convention.

Read the full discussion online.

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

To start a new discussion for this project, email nupack@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


Sep 10, 2010 at 7:49 PM

Not familiar with it, but it doesn't sound like it based on the thread above.  If the user can use a --pre switch to specify that they want a pre-release version, they're not making an assumption on a naming convention.  They use a clear switch which works with any package.  Right?

Sep 10, 2010 at 7:55 PM
so, in gems if a user wants a given package say 'nhibernate' and they want the beta/edge/soon to be awesome release they simply type

gem install nhibernate --pre

if they want the stable one they type
gem install nhibernate


ruby gems determines if something is prerelease based on the semver concepts. so if you register version
1.0.0.0
1.2.0.0
1.3.0.0

if you register
1.4.0.0ctp1

that would be the --pre selection.

then you release 1.4.0.0 and that becomes the next stable

pre releases are in alpha order so two ctps for 1.4.0.0 would be sorted like so

1.4.0.0ctp1
1.4.0.0ctp2

does that help?
-d

On Fri, Sep 10, 2010 at 2:49 PM, davidebb <notifications@codeplex.com> wrote:

From: davidebb

Not familiar with it, but it doesn't sound like it based on the thread above.  If the user can use a --pre switch to specify that they want a pre-release version, they're not making an assumption on a naming convention.  They use a clear switch which works with any package.  Right?

Read the full discussion online.

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

To start a new discussion for this project, email nupack@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


Sep 10, 2010 at 8:02 PM

I see.  But then we are mostly in agreement.  There is a naming convention on the producer side, but the consumer doesn't need to deal with that in order to successfully install the stable vs the pre-release package (since the clear --pre takes care of that).

Sep 10, 2010 at 8:04 PM
:)

-d

On Fri, Sep 10, 2010 at 3:02 PM, davidebb <notifications@codeplex.com> wrote:

From: davidebb

I see.  But then we are mostly in agreement.  There is a naming convention on the producer side, but the consumer doesn't need to deal with that in order to successfully install the stable vs the pre-release package (since the clear --pre takes care of that).

Read the full discussion online.

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

To start a new discussion for this project, email nupack@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


Coordinator
Sep 10, 2010 at 9:53 PM

Let’s log an issue on this, if there isn’t one already.

Sep 10, 2010 at 9:59 PM

I think I already created one, the running with scissors feature. It may need updated though.

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

Oct 8, 2010 at 7:47 AM

Is there a way to control versioning in VS UI?

I take it this is possible with power shell but frankly going to power shell is just about the same effort for me as managing my dependencies manually :)

Andrei.

Oct 8, 2010 at 1:43 PM

I understand this is an old thread, but it concerns me that the principle developers of NuPack haven't researched the current state of the art in package management.

I think it's fine to take notes from gems but at the same time there is no package manager in .net today so you can't assume that there is even a convention that people know(every .net dev hasn't played with gems). We can come up with our own conventions that makes sense for .net packages, whatever that is.

This comment especially. First of all, there are other .NET package managers available. Just not developed by Microsoft. But that's besides the point.

We need to stop acting like .NET devs are somehow special and that nobody else has similar problems. Let alone haven't come up with solutions to these problems independent of Microsoft. This constant re-inventing of the wheel is annoying. If you're going to "borrow" from other projects, at least take the good parts as well. Why create new conventions when there are existing ones that have been proven to work?

If you want to deviate from existing conventions, then you should come up with a valid reason why. And ".NET devs don't know any better," is not a valid reason. This patronizing from Microsoft is frankly insulting.

Oct 8, 2010 at 1:54 PM
http://semver.org

For versioning number scheme that is awesome sauce.


For the last several months I have been digging into debian's apt-get + the research into ruby gems have given me much appreciating for the thought and effort they have put in. I would highly suggest that anyone interested in nupack do the same.

-d


On Fri, Oct 8, 2010 at 8:43 AM, kiliman <notifications@codeplex.com> wrote:

From: kiliman

I understand this is an old thread, but it concerns me that the principle developers of NuPack haven't researched the current state of the art in package management.

I think it's fine to take notes from gems but at the same time there is no package manager in .net today so you can't assume that there is even a convention that people know(every .net dev hasn't played with gems). We can come up with our own conventions that makes sense for .net packages, whatever that is.

This comment especially. First of all, there are other .NET package managers available. Just not developed by Microsoft. But that's besides the point.

We need to stop acting like .NET devs are somehow special and that nobody else has similar problems. Let alone haven't come up with solutions to these problems independent of Microsoft. This constant re-inventing of the wheel is annoying. If you're going to "borrow" from other projects, at least take the good parts as well. Why create new conventions when there are existing ones that have been proven to work?

If you want to deviate from existing conventions, then you should come up with a valid reason why. And ".NET devs don't know any better," is not a valid reason. This patronizing from Microsoft is frankly insulting.

Read the full discussion online.

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

To start a new discussion for this project, email nupack@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


Oct 8, 2010 at 9:59 PM
SemVer FTW!!!
 
It's so simple and it aligns with what many of us do already with respect to active versioning.  UppercuT (http://projectuppercut.org) supports both passive and active versioning. The active versioning model it follows is semver.
 
Soon it will have nupack as one of the outputs for you automatically. Just a note.  I thought I'd mention it because it will help with the versioning aspect with your packages.
Oct 9, 2010 at 5:56 AM
Edited Oct 9, 2010 at 5:57 AM

gem uses --pre to install unstable versions.

but can we have one more for a particular version.

nupack nhibernate --pre=3.1 (nupack nhibernate /pre:3.1)

or

nupack nhibernate --version=3.1 (nupack nhibernate /version:3.1)

shorthand

nupack nhibernate -v=3.1  (nupack nhibernate /v:3.1)

i prefer --version or -v. but can still support --pre without versioning.

if the user types nupack nhibernate --pre it will pull the latest unstable version. which would be equivalent to

nupack nhibernate --version=latest-unstable (nupack nhibernate /version:latest-unstable)

-------

this idea came from git which has certain constants like HEAD, which referts to the last commit number(hash).

so nupack can also have constants such as "latest-unstable", "latest-stable" (or "latest"). This allows the devs to download the latest unstable without knowing the version (It saves time opening the browser checking what is the latest version or doing list in nupack).

Oct 9, 2010 at 11:49 PM

This is the kind of discussion I'm talking about.

Actually I don't think you need a special --pre=3.1. I think --pre should be a modifier to the current command.

No version, no pre = latest stable version

Version, no pre = specific stable version

No version, Pre = latest unstable version

Version, Pre = specific unstable version

Note: this will get latest unstable of specific stable, so --version=3.1 --pre would return 3.1beta2 instead of 3.1beta1. I believe thats a reasonable expectation since dealing with pre-release software, you're more likely want to get the latest version since it will most likely have bug fixes, etc.

I also like that you're looking at projects outside of package management for ideas. Whether or not we need specific constants for this feature is worth discussion, but thanks for thinking outside the box.

Kiliman

Coordinator
Oct 10, 2010 at 12:15 AM
This sounds to me it could be as easy as adding one piece of metadata to nuspec, "prerelease". If true, then --pre is required.
>
Oct 10, 2010 at 3:03 AM

NuPack definitely needs a metadata tag, to differentiate between stable and unstable.

either <prerelease>true</prerelease>

or <stable>true</stable>

prerelease sounds cool.

Developer
Oct 10, 2010 at 3:49 AM

Maybe. I think we might just change how we version packages.

Oct 10, 2010 at 5:29 AM

With gems you just put alphabetical characters at the end of the version and it knows that is a prerelease. I really like that convention. Thoughts?

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

Developer
Oct 10, 2010 at 5:35 AM

I know you've been really pushing semver from the beginning :D. I think we'll look at the options. I prefer that approach rather than extending metadata though.

Oct 10, 2010 at 1:27 PM

Extending metadata? I'm a little confused. Semantic Versioning is just really good guidance into how to version and is only a small thought change. I think most of us do versioning very similar to SemVer.

Current .net versioning octets are: major.minor.build.revision
SemVer: major.minor.patch

Major and minor are used the same, semver gives guidance into when those numbers should change. The next octet, build, is used as patch instead. The last octet is always zero.

So version 1.0.0.0 in .net is 1.0.0.0 with semver. A fix (or patch) to that is 1.0.1.0. A compatible non-breaking api change or internal change is 1.1.0.0. An incompatible change to the public api ia 2.0.0.0.

It's really not that different and .net is 100% compatible today.
____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

Oct 10, 2010 at 1:28 PM
I hope we can keep the version semantics as close as possible to Gems, it'll make interoperability and porting of packages a lot easier...

Perhaps a ping to the Gems folks to see if there are any things they wish were different would be wise too.

On Oct 9, 2010, at 8:15 PM, Haacked wrote:

> From: Haacked
>
> This sounds to me it could be as easy as adding one piece of metadata to nuspec, "prerelease". If true, then --pre is required.
> >
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email ([email removed])
>
> To start a new discussion for this project, email [email removed]
>
> 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
>
Coordinator
Oct 10, 2010 at 4:25 PM

@ferventcoder What I think David is saying is he prefers the Semantic Versioning approach better than my suggestion to add more package metadata. Earlier I proposed the idea that we simply add a “pre-release” bit to nuspec. So when creating a package, you’d specify whether the package is pre-release or not.

I could go either way honestly. Either way, it’s extra metadata you specify in nuspec. Either you’re adding characters to the existing version field, or you’re setting a different bit. How widely adopted is Semver among our users and does it even matter if they adopt it if they continue to do whatever it is they’re doing now?

I think Semver is worth investigating at this point as a potential solution to identify pre-release vs stable.

Oct 10, 2010 at 7:40 PM
I agree that we should use Semantic Versioning; the Ruby Gems community has some experience in this regard, and I think it'd be fairly wise to follow their lead.

Also, perhaps someone with Ruby Gems connections could ping them and find out what they wish they could change or had done differently? (Maybe one of the original #nuproj folks?)

On Oct 10, 2010, at 12:26 PM, haacked wrote:

> From: Haacked
>
> @ferventcoder What I think David is saying is he prefers the Semantic Versioning approach better than my suggestion to add more package metadata. Earlier I proposed the idea that we simply add a “pre-release” bit to nuspec. So when creating a package, you’d specify whether the package is pre-release or not.
>
>
> I could go either way honestly. Either way, it’s extra metadata you specify in nuspec. Either you’re adding characters to the existing version field, or you’re setting a different bit. How widely adopted is Semver among our users and does it even matter if they adopt it if they continue to do whatever it is they’re doing now?
>
>
> I think Semver is worth investigating at this point as a potential solution to identify pre-release vs stable.
>
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email ([email removed])
>
> To start a new discussion for this project, email [email removed]
>
> 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
>
Coordinator
Oct 10, 2010 at 8:00 PM

I pinged Nick Quaranto (founder of rubygems.org) about this question among others. I'll be milking his brain for a while. :)

Oct 10, 2010 at 8:04 PM
As much as is reasonable, I hope we can keep NuPack and Nu compatible. Following Gem's inspiration will help with that.

On Oct 10, 2010, at 4:00 PM, Haacked wrote:

> From: Haacked
>
> I pinged Nick Quaranto (founder of rubygems.org) about this question among others. I'll be milking his brain for a while. :)
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email ([email removed])
>
> To start a new discussion for this project, email [email removed]
>
> 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
>
Apr 7, 2011 at 3:10 PM
Edited Apr 7, 2011 at 3:12 PM

Did this feature ever get implemented? I believe that this is fundamental if you want to use NuGet for dependency management for internal projects

 

UPDATE: Disregard. I just saw that there's a more recent thread about this.

http://nuget.codeplex.com/discussions/226384

Coordinator
Apr 7, 2011 at 3:37 PM

Not yet, but we plan to soon. We had to scale back our 1.3 plans a bit because some of us will be at Mix. J