Snapshot functionality

Dec 13, 2010 at 11:51 AM

Is there any way to achieve some sort of snapshot functionality in NuGet?

I am currently developing a library in which I use in another project currently under development. Every time I do something in the library I have to increase the version number to be able to update the package in the other project. What I want to achieve is to name the NuGet package version something like "1.0-SNAPSHOT" so that when I call Update-Package in Package Manager it reinstalls the package. Are there any plan of this sort of functionality?

I don't know if i made myself clear? :)

Coordinator
Dec 13, 2010 at 4:56 PM

No plans for that functionality. Wouldn't be simpler for us to have a flag that is effectively a force update? Or why don't you just uninstall then install the package. You could even write a simple PS command that does it.

Dec 14, 2010 at 7:31 AM
Edited Dec 14, 2010 at 7:38 AM

Yes, you are probably right. I have now started writing a PS script in which update the .nuspec file with new version numbers ( *.*.*.TimeStamp ) , builds the package, deploys it to our internal repository and deletes the older packages from there so that it will not fill up. I will also name the package something that indicates this is not a release but a snapshot. :)

Anyway, I thank you guys for a wonderful tool :)

Dec 22, 2010 at 6:34 AM
hansos wrote:

Is there any way to achieve some sort of snapshot functionality in NuGet?

I am currently developing a library in which I use in another project currently under development. Every time I do something in the library I have to increase the version number to be able to update the package in the other project. What I want to achieve is to name the NuGet package version something like "1.0-SNAPSHOT" so that when I call Update-Package in Package Manager it reinstalls the package. Are there any plan of this sort of functionality?

I don't know if i made myself clear? :)

I would also love to see this feature, as this is exactly what Maven does.  It is very useful when you want to have the bleeding edge version of a library package without any fuss.

Coordinator
Dec 22, 2010 at 3:41 PM

Please log a detailed issue for this please and we'll consider it. We would probably want to ensure that packages cannot be uploaded to our main gallery with a snapshot version as that would not be good. This is intended only during development, correct?

Dec 22, 2010 at 4:53 PM

You would want to upload the snapshot to the gallery, as it allows other users of the package to get the latest features, but is very much seen as being the 'beta' version until a "RELEASE" is made. This snapshot would be constantly updated until you release and then roll over into the next version. It is a slightly different paradigm to the 1.0.0.buildnumber concept that is prevalent in .net where the buildnumber is the next one off the build server. 

Sorry if any of my comments are ill informed, but I am just starting to have a look at NuGet, after developing in Java land for a while. And Maven's dependency management have been one of the highlights of being away from .Net.

If you guys haven't had a look at Maven already I would suggest you find a friendly Java dev who knows Maven and have a look. Maven is far from perfect, but there is a lot of stuff there including repository structure, pluggins, snapshots, etc. It might be good for you to see what is good and where they went wrong. 

Keep up the good work.

Dec 22, 2010 at 7:11 PM

What rich_r said is correct.  Maven rightfully allows one to upload a snapshot to the repository.  Without this, no other teams would ever be able to consume your packages.  However, there is one little catch later on down the road... You cannot execute a "maven release" command when any of your dependencies are snapshots :-).  This effectively keeps the snapshots in development. 

Since NuGet is strictly a dep. management tool (for now), there is nothing to prevent snapshot dependencies from going out into the wild.  To be fair, a java developer can simply bypass the maven release stuff and simply shove his jars onto the production server just as easily as a .net developer can.  It's just that Maven does try to prevent this.

http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html See the second bullet point.

Dec 22, 2010 at 8:18 PM

The need for beta packages to be in the feed has come up before, though we haven't yet fully tackled it.  But note that nothing is blocking beta packages from getting into the feed today.  You can just use a different id for then.  e.g. use "MyPackage.Beta" instead of "MyPackage" (though we do need to formalize that).

rich_r, not sure I understand the part about not using the build number.  I would think if you keep updating your beta, you should update the build number (or some part of the version string) on every update, so the system knows there is something to update to.  Can you clarify?

Dec 22, 2010 at 8:24 PM
davidebbo wrote:
rich_r, not sure I understand the part about not using the build number.  I would think if you keep updating your beta, you should update the build number (or some part of the version string) on every update, so the system knows there is something to update to.  Can you clarify?

Maven can be configured to always force-download the latest snapshot, even if version number is the same:

Each repository in the project has its own update policy:

  • <tt>always</tt> - always check when Maven is started for newer versions of snapshots
  • <tt>never</tt> - never check for newer remote versions. Once off manual updates can be performed.
  • <tt>daily</tt> (default) - check on the first run of the day (local time)
  • <tt>interval:XXX</tt> - check every XXX minutes

More info here: http://docs.codehaus.org/display/MAVEN/Repository+-+SNAPSHOT+Handling

 

Dec 22, 2010 at 8:57 PM

Having a hard time putting together "even if version number is the same" and "always check when Maven is started for newer versions of snapshots".  It sounds like 'always' is about checking for updates, but that in order of the update to actually be performed, a newer version needs to be available?

Dec 22, 2010 at 9:23 PM

Sorry, I wasn't very clear.

Scenario: I'm working on a small shared library.  It is in snapshot mode.  Let's say 0.9-SNAPSHOT.  This means every time I deploy to the repository, the version number does not change, it just deploys over the top of 0.9-SNAPSHOT, as snapshots are not treated with the same caution as full releases.  Along comes a project that consumes my little library.  If they specify to "always" pull down the latest snapshot version, the local copy of this package will be ignored and a force-refresh from the server will happen, as something may have changed (even though the version number is the same).

Hope that makes sense.

Many projects/firms even have separate snapshot repositories to keep them very far apart from "real" packages.

-Alan-

Dec 22, 2010 at 10:11 PM

Understood.  So I think what haacked suggested above is a decent alternative: "Wouldn't be simpler for us to have a flag that is effectively a force update? Or why don't you just uninstall then install the package. You could even write a simple PS command that does it.".  Note that we don't really have any concept of automatic updates based on a schedule, but I think the key part of what you describe is the ability to re-install an already installed package, to make sure you get the latest even if the version is the same.  And a -force flag would achieve that.

Dec 23, 2010 at 7:30 AM

Certainly a -force flag would achieve the same result, as would uninstalling/reinstalling.  However this is a manual step which is not that nice.  I could envision a developer consuming a "snapshot" (beta) package would default to always using the -force flag.  If the developer is going to use it that often, why not just build in a convention that does this automatically based on a version number or a tag?  That would be my preference.

Nov 15, 2011 at 12:20 PM

I'd very much like to see first class support for snapshot repositories, especially private snapshot repositories but I have come up with a workflow that handles snapshots fairly well here, its easy to implement, and could easily be added to the NuGetPowerTools.  Here is my strategy...

Build using Debug configuration - Restore packages (NuGetPowerTools), Compile

Build using Release configuration - Restore packages, NEW task that runs "nuget update -safe", Compile

My CI server compiles using the Release config and it will compile against the "latest" every time.  Developers use Debug config most of the time but they will be prompted by NuGet when there are updates and I expect them to handle that.  You could also run the update while in the Debug config but I don't want my developers slowing down their compilations so I did not.

 

This strategy is dependent on snapshots working within the -Safe update parameters and a new MSBuild target which is trivial to write.  I've created this target separately to my projects but it could also be added to the NuGetPowerTools easily.

Mar 29, 2012 at 2:55 PM

I don’t like the idea of "automatic update" option. This is not that simple. If you have a release version as dependency, you passed through exhaustive tests. A simple automatic update would break a stable code.

The snapshot concept is only related to development. And once you’re developing a new code, you are changing the next version (flagged as snapshot). Why? It’s simple: once published a release you cannot change it because there would be other projects depending on this code. Nuget doesn’t seem to have this concept implemented and yes, I could write a simple script to update packages, but why not have it standardized inside the tool?

Having snapshot packages is an amazing feature that I really look forward having it also present in .NET projects.