Hi @sejhemming_5842
Is there an accepted Code of Practice for managing prerelease stuff?
Yes, the general rules to follow are these:
Packages are immutable; do not delete/republish packages as part of your normal workflow
Use Prerelease Packages & Repackaging to take tested/validated prerelease packages to stable packages
Use Package Promotion to move packages across feeds
Use Retention Rules to automatically cleanup unused prerelease packages
Do people publish prerelease stuff to a different feed and only post the released stuff to the more public feed? Or is it just expected that once the release is out that the prerelease builds are simply removed from the feed?
Yes to both
On our ProGet Instance, we use both patterns.
Extensions (plugins) have two feeds: Extensions (Stable) and PrereleaseExtensions; the reason is that we use CI (build automation), and publish a new package on every commit, and these could be really unstable - we don't want anyone using a prerelease extension unless we explicitly point them to it
Our NuGet libraries have one feed (NuGetLibraries) that has both prerelease and release packages; these are not intended for anyone other than Inedo Engineers, and we have policies, practices, and training in place to make prerelease packages are shipped appropriately
My advice for deciding which pattern to follow would be looking at the consumers of your feeds/packages (i.e. who uses your packages vs who publishes your packages).
Using a single feed that has release and prerelease packages requires more training for developers. If one of your developers accidently uses a prerelease package and commits that, then it's going to cause problems. Even if you catch it before production, it will waste time and resources.