2

I'm getting started with a Continuous Integration Nuget feed for my team using a network share. After each build to the dev environment, a package will be created on the network share using the versioning scheme Major.Minor.Patch.BuildNumber. Example: "MyPackage.1.1.3.16338.nupkg".

I was planning to have apps reference these packages on the local feed, and whichever package version is released to Production is published to Artifactory and considered the latest "stable" package/build.

The problem is, I know the versioning scheme doesn't conform to Semantic Versioning and I don't like the ugly build number at the end of the version.

Is there a better way to do this, so I end up with a simple 1.1.3 version to publish to Artifactory at the end of a release cycle?

user2966445
  • 1,267
  • 16
  • 39

1 Answers1

0

Is there a better way to do this, so I end up with a simple 1.1.3 version to publish to Artifactory at the end of a release cycle?

I think the best way to do that is using versioning scheme Major.Minor.Patch instead of Major.Minor.Patch.BuildNumber, otherwise, you have to manually change the package version from 1.1.3.16338 to 1.1.3. Because there is no such option or task that we could change the package version after creation.

As an alternative, you could use nuget task NuGet custom to create the nuget package:

enter image description here

NuGet task: Command: custom

Command and arguments:

pack $(Build.SourcesDirectory)\Package.nuspec -Version $(version) -OutputDirectory $(build.artifactstagingdirectory)

In this case, you can specify the nuget package version in the command line.

See This thread for some more details.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135