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!
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.