NuGet 1.6 Gallery Endpoint Changes

As you know, we've been working on a new implementation of the gallery that supports the changes coming in NuGet 1.6. For example, we will support SemVer for packages. There's an upcoming change to SemVer that's not yet released, but will be soon. We based
our implementation
on that spec.

More importantly, we're simplifying the URL structure for NuGet 1.6 endpoints for publishing packages. These are the endpoints that nuget.exe and package explorer will point to in order to publish packages. We'd also like to do the same for the OData feed,
but we're going to save that for 1.7 as we're trying to avoid scope creep.

-Does this count for the consumption of packages as well? E.g. when I add http://www.myget.org/F/somefeed to VS2010, will it consume that feed or will it try to consume http://www.myget.org/F/somefeed/api/v2
?

My understanding of the spec is that for everything other than one-feed-per-domain, we'll need to specify the full endpoint path, because nothing will be appended automatically? That's going to degrade the experience of MyGet and SymbolSource users a bit...

One idea that comes to mind is to do redirects on the server-side based on User-Agents:

Maarten, I think the original goal was to allow backward compatability, i.e. to be able to use a 1.6 client to push to a 1.5 server. In your scheme the 1.6 client would try to append 1.6 paths to full 1.5 urls. To make this work it would have to know the
list of all possible suffixes (current api version and all previous versions) and check those to see if it should append the default (current version, api/v2/something).

That would still be possible: if my feed endpoint remains "http://www.myget.org/F/somefeed", I can keep the routes for the old 1.5 urls as well. No breaking changes and support for both 1.5 and 1.6 clients, even
without explicitly specifying the publish URL.

That would still be possible: if my feed endpoint remains "http://www.myget.org/F/somefeed", I can keep the routes for the old 1.5 urls as well. No breaking changes and support for both 1.5 and 1.6 clients, even
without explicitly specifying the publish URL.

Maintaining old routes only takes care of client=1.5 and server=1.6, I was talking about the opposite.

Note that the NuGet 1.6 server won't put the API Key in the URL any longer. So while you do have to specify the full URL in your case, it's not as long as it used to be.

The problem with always appending /api/v2 is for folks hosting internal NuGet galleries. Using NuGet 1.6 to post to them would be impossible without them upgrading them. While we
want folks to upgrade their servers, that's a bigger undertaking than upgrading nuget.exe and we don't want to force them to do it on our timeline necessarily.

-Does this count for the consumption of packages as well? E.g. when I add http://www.myget.org/F/somefeed to VS2010, will it consume that feed or will it try to consume http://www.myget.org/F/somefeed/api/v2
?

I'm a bit affraid that users will need "yet another" URL as MyGet (and SYmbolSource) use part of the path to identify the feed. The current spec linked to in the opening post of this topic really limits flexibility in this as it only allows one NuGet feed
per domain?

May I ask why are you guys pushing this now in 1.6? Why not postpone it altogether to 1.7, to find a good solution for both the push URL and feed consumption URL? Aren't you afraid that the scheme will need to change again in 1.7 and that we'll all end up
with 3 schemes out there instead of 2?

What will the exact request sequence be? At this moment nuget.exe push -Source http://server/path first makes a GET to /path (I have no idea what for, because we return 404 at SymbolSource and it still works) and then a POST to /path/key/whatever. Will it
now be only POST?

@maartenba sure. That could work. Since you have a custom implementation of the gallery, you could just route http://www.myget.org/F/somefeed directly to the controller actions that handle those requests.

@tripleemcoder because if we wait till 1.7, as soon as 1.6 comes out, anyone who upgrades nuget.exe is broken with
no workaround. We had to version the feed because of the pre-release SemVer support made it impossible to have the feed URL stay the same and be backwards compatible.

For consuming the feed, we have a way to change the URL that will be backwards compatible. We can use a discovery mechanism much like the way RSS readers discover the RSS feed endpoint. Handling the read case is much easier than the push/delete case.

@tripleemcoder because if we wait till 1.7, as soon as 1.6 comes out, anyone who upgrades nuget.exe is broken with
no workaround. We had to version the feed because of the pre-release SemVer support made it impossible to have the feed URL stay the same and be backwards compatible.

Can you elaborate on this? I don't see why SemVer would break the push endpoint (in terms of URLs, in terms of backend processing and logic - that's obvious), which probably means that I don't understand something. And I really should for SymbolSource's
sake ;)

Does this count for the consumption of packages as well? E.g. when I add http://www.myget.org/F/somefeed to VS2010, will it consume that feed or will it try to consume http://www.myget.org/F/somefeed/api/v2 ?
We will consume http://www.myget.org/F/somefeed

If I push to http://www.myget.org/F/somefeed, will NuGet use that as the endpoint for push? Or will it be http://www.myget.org/F/somefeed/api/v2/package (which I would prefer)
It would use the former without appending anything. For sake of compatibility with older clients, NuGet gallery would keep existing routes around for a while. NuGet.Server would not be doing this. Additionally, the api key would be sent as part of a header
named X-NuGet-ApiKey.

In short: if I have this URL to a feed, what will all the required endpoints be?
We're implementing the following endpoints in the upcoming gallery:

A new question then: will it be possible to hard delete a package through the gallery? I understand the intentions, but I also remember the same issue at SymbolSource. People simply want to be able to delete stuff.

SymbolSource is almost ready too, but we're low on resources at the moment and will need extra 1-2 days for testing and final corrections.

Also, nuget.exe 1.5 handled server errors by displaying anything sent back from the server with a 500 status code. The current build of 1.6 ignores all content. We would very much like to be able to send back multi-line descriptive errors like we have so
far. This greatly helps in diagnosing symbol package validation errors.

Ok, I have a bit of a concern. The NuGet Gallery project restores one package from a private MyGet feed. We just updated the gallery to use NuGet.exe 1.6 to restore that package. Well of course that fails, because MyGet hasn't yet pushed their 1.6 changes
live.

Now, as we all discussed, there's a workaround. I can put my API Key in the URL and craft it to use the full URL temporarily. But when MyGet switches to 1.6, my build breaks again. How annoying!

Could I convince you MyGet folks to consider a v2 versioning scheme for your URLs as well? :) That way my existing build using NuGet.exe 1.5 doesn't break. And when I upgrade to NuGet.exe 1.6, I can simply point it to the v2 feed. That would allow you to
start publishing the 1.6 compatible feed URLs today. :)

I believe this is the class of computer science problems known as the "chicken / egg" category. :P