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

#1

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?

Example: https://bldr.habitat.sh/#/search;q=libfcgi

#2

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.

#3

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

#4

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
#5

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