How to get beta packages

Sep 7, 2010 at 9:49 PM

Gems has this concept of --pre to get a beta.  All you have to do is include alphabetical characters after the last version bit and it automatically knows it's a beta when you upload it. So when people ask for the package, they get the latest one NOT the beta you uploaded. When they ask for the package with the special key.

I'm for calling this the --beta feature. :D

Sep 7, 2010 at 9:58 PM

I think this is an imporant feature. Call this the running with sissors feature

Sep 7, 2010 at 10:00 PM

I don't expect this one to make it into v1 due to deadlines, but definitely for vNext. And having vNext in like October/November. ;-)

Mar 24, 2011 at 5:25 AM

Hi all,

Been doing some planning around this feature and wrote up a spec here. Please take a look and let us know what you think. As always, we're trying to keep it as simple as possible for this iteration. Hopefully this implementation idea is good enough for the time being and if we have even cooler ideas, we can implement them later.

But if the feature spec is fundamentally flawed, we'll want to know that, or if there are easy improvements that will make it much better or much simpler.

Thanks for your feedback!


Mar 24, 2011 at 6:12 AM

Note that we had a previous discussion on this with some good content. My first reaction reading the proposal (I missed the meeting where this was discussed :) ) is that it seems a bit over-engineered compared to the naming convention approach.

What if declaring a beta package was as simple as naming it something like "SomePackage.beta" (or alpha, or some other known tokens), with no changes to the nuspec format nor the feed format?

Then we could build some smart in the client such that doing 'install-package -beta SomePackage' really means 'install-package SomePackage.beta', so the client experience would be similar to what your proposal describes.

And if we don't want to show pre-release packages in the dialog, it would be a matter of filtering out those that end with .alpha, .beta, ...

There are probably a few tricky issues to solve, but on the surface it seems solvable, and a much smaller scope feature than adding new flags in the nuspec and feed.


Mar 24, 2011 at 6:23 AM

I’m concerned about all the places we’d need to change our “ID” matching logic. For example, suppose I have “SomePackage” installed. Will Upgrade-Package SomePackage –Prerelease upgrade me to SomePackage.beta even though the ID is different? That’s the desired behavior, but it feels wrong that we changed the ID.

If we support multiple pre-release tokens, we have more problems. What if there’s SomePackage.ctp and SomePackage.beta in the feed. Which one does Install-Package SomePackage –Prerelease install? Which one does Upgrade-Package SomePackage –Prerelease upgrade me to?

Also, this would mean our OData feed needs to do a textual filter to filter out pre-release packages, which could be inefficient.


Mar 24, 2011 at 6:52 AM

The idea is that there would be a flag per type of pre-release we choose to support (e.g. -alpha, -beta, -ci). Also, is having the ID change from SomePackage to SomePackage.beta that big of a deal when you explicitly ask for a -beta update?

But stepping back, I'm almost wondering whether we're over-thinking this and should instead just advertise the naming conventions with no client smart at all. We would lose the auto update from beta to release but maybe it's not a deal breaker to manually uninstall/install.

I guess it comes down to what need users really have relating to this. My take is that the biggest concern today is that saying 'install foo' or 'update foo' might get you a beta package when you didn't want that, and the simple naming convention addresses that part.

I'm just trying to make sure we don't go down a big/expensive path that goes beyond what the actual user need calls for.

So let's hear it from others in Texas, Kansas and elsewhere :)

Mar 24, 2011 at 6:56 AM

Yeah, I do want to hear from others, but let me say one more thing because not only am I on the NuGet team, but I’m also a customer ;).

The reason I think keeping the ID is important is this.

Package A depends on B.

<dependency id="B" version="1.0" />

Let’s say I install A and thus have B. I should be allowed to upgrade B to 1.1 Beta. But that might not work if 1.1 Beta is really B.beta.

I mean, this is a scenario *I’ve* run into in the past (without a dependency manager of course).


Mar 24, 2011 at 7:10 AM

Agreed, that's a good scenario to keep in mind. Note that the assembly names would stay the same, so you could technically use B.beta. But without client magic, getting rid of B 1.0 would require the -force flag, which is dirty.

Mar 24, 2011 at 4:18 PM

Yeah, that's what I'd like to avoid. I updated the spec with a simple list of scenarios I think are important. Maybe agreeing on that first is the best approach:

  • Filtering out pre-release packages and pre-release package versions.
  • Explicitly viewing pre-release packages.
  • Upgrading from pre-release to release.
  • Upgrading from release to pre-release (including when other packages have a dependency on that package).
  • Release package taking a dependency on a pre-release package.
  • Coordinator
    Mar 24, 2011 at 5:24 PM

    We talked about this a bit and started to wonder how necessary is this feature at all?

    For example, there are some negative consequences.

    • Not yet released packages will get no visibility. EFCodeFirst is a good example. It's been a pre-release package, but it's our most popular one. If it had been marked as pre-release, it wouldn't have shown up by default.
    • The choice of "pre-release" is arbitrary and up to the whims of the package author. There's no consensus on what this means nor any standardization. So do you really get any benefit?

    What if we simply recommended users use metadata to describe the state of the package and let users make a decision there? now has support for a "recommended" release in the gallery. By default, when you upload a package, the latest release is marked as the recommended release. But you can change a recommended release which would allow you to have an even newer release (aka pre-release) that's not the recommended. That's one way to support the general idea of pre-release packages that's really really simple and cheap.

    For example, we could have a pre-release tag and when you push a package with that tag, we don't mark it as recommended leaving the recommended package as the recommended one.




    Mar 28, 2011 at 5:42 AM
    What is currently written up on the wiki (version 5 is really good stuff. I can dig it.

    I like that it is still the same package name with a prerelease bit in it. That makes sense to me and seems the simplest and most elegant route.

    I also like the idea (also on the wiki) that nuget pack could flip that bit for me if I had alphabetical characters suffixing my version.