Should we move artifacts to private after merge into core-plans?

Would it be a good idea, after getting a package merged into core-plans, to delist builds I’ve previously published under my own origin via Change a package from public to private in the depot ?

Or is that not the intended use of the private channel? Is there a better approach in mind already or a reason not to do this?


I don’t think we have an official policy around this. In my opinion, it’s perfectly fine to keep it in your own origin.

I don’t have any reason or desire to want to keep them listed, I’m more wondering what the best consumer experience is

People coming across a choice between a supported and unsupported package vs disappearing something that’s already been listed

While I’m not sure this deserves a “policy” since I could envision a scenario where one might want to use the former origin for some reason, I think if you have a package that others are using and then move that package into core, one strategy would be to Build a new release in the former origin that:

  • is just an empty package that takes a dep on the core package (library packages only)
  • Emits a warning in the build notifying on the new core package
  • emits output in the init hook stating that the users should use the core package (service packages only)
  • Make it clear in the old readme of the core package
  • Make the package private in builder so it will not show up in searches
1 Like

I’m pretty sure no one is using my example case yet, it’s only been published as long as the PR has been open… so probably safe to just disappear it but I @mwrock’s approach for anything that’s been in the wild on its own for a bit