1

maybe someone has a good idea for the following scenario:

I have prerelease dev packages, like that: packagename.1.2.0.1000-dev.nupkg and release packages, like packagename.1.2.0.1.nupkg

My idea was: starting at a higher number range for the dev packages would always allow getting the dev packages for developers if they enable the Pre-Release option at the nuget update step. This works fine. Then later on I would like to update the project to the latest release version. But it seems there is no option to update to the latest release version that has a lower version number than the dev/pre-release package? Also the -Safe option doesn't seem to work here.

I can't keep the build numbers in sync also since these are different builds. If I have it the other way around, so higher build numbers for the release versions, it would never update to the latest dev packages if I do a normal nuget update, even including the pre-release packages...

Any idea here?

Thanks a lot!

user250773
  • 569
  • 1
  • 8
  • 21
  • I recommend using [semver](https://semver.org/), not the old four digit scheme. Either way, you have to use whatever scheme you choose, correctly. You're not doing that. See https://learn.microsoft.com/en-us/nuget/reference/package-versioning. – jwdonahue Nov 04 '18 at 16:52
  • Hi. ok I got the point for the semver to only use 3 digits or new semver 2.0 allowing dot notation. but as far as I can see that would not resolve how to update to only release packages, even if (since it is an automated build), the last build/version number of the prerelease package might be higher than the one from the released version – user250773 Nov 05 '18 at 07:25
  • It's always up to the client whether to allow prerelease packages. – jwdonahue Nov 06 '18 at 21:07

1 Answers1

0

Any package that is publicly available is a "release package" in technical/English terms. But the software industry has bastardized the language. So lets talk about stable (no prererelease tag) and unstable releases (prerelease tag).

The publisher history should be something like this:

1.0.0 // First **stable release**
1.0.1-alpha // First **unstable release** Candidate bug fix.
1.0.1-beta  // 1.0.1-alpha with a tweak to the code.
1.0.1 // Second **stable release**

If the publisher follows that pattern, then end-user clients can safely pull stable release bug fixes while developers can also pull unstable prereleases at their discretion.

You can also have something like:

1.0.0 // First **stable release**
1.0.1-a.dev.1 // Next CI build after 1.0.0
1.0.1-a.dev.2 // Etc...
1.0.1-alpha // Relabeled 1.0.1-a.dev.2.
1.0.1-beta  // Relabeled 1.0.1-alpha, wider audience than -alpha.
1.0.1 // Second **stable release**

It's a good practice to have separate feeds for internal dev/test, public prerelease and public stable releases.

jwdonahue
  • 6,199
  • 2
  • 21
  • 43