Allow authors/publishers of orbs to manage deprecation of their orbs, giving them the ability to more adequately manage the orb's support lifecycle. Authors/publishers of orbs are potentially expected to support all published versions of an orb. Allowing publishers to deprecate and/or remove older versions of an orb would prevent authors/publishers from having to support older versions of an orb which may contain issues fixed in later versions.

Many organizations using orbs would most likely want to publish their orbs privately. I assume orbs will be scoped to your GitHub org as namespace? So it would be great if we can publish orbs to foobar/wizzle (assuming GH org foobar), and to have those be only visible to users / jobs within org "foobar" CCI-I-606

Currently "Allow Uncertified Orbs" of "Orb Security Settings" have binary option to allow to use third-party orbs or not.We wish to use WHITE LIST orb provider. CCI-I-687

I want to be able to define an entire workflow in an orb, using the jobs of my orb and allowing parameters to conditionally choose which jobs to run and allow parameterization of branch and tag filters as well. CCI-I-615

This would help document orbs with non-trivial features needing lists, references (links), not to mention general niceities like italics and bold are just routine tools of good prose. CCI-I-977

Could be a project level API key with publishing permissions, or use team membership like contexts do. Some means to expand the population of folks who can deploy prod versions of orbs without giving them global admin rights in GH. CCI-I-1108

It'd be useful to allow handling lists of values for a parameter, without having to resort to workarounds like parsing comma-separated lists in string types. I think it would be useful to be able to specify something like: steps: - myorb/foo: bar: - baz - qux And have the myorb/foo command called with a bar parameter equal to [ "baz", "qux" ] . CCI-I-701

to loop over a list of items example: docker tags CCI-I-918

While the Configuration tab does say # Orb 'foo/bar@1' resolved to 'foo/bar@1.0.1', it would be nice if the actual build would show the version of an orb being used at startup when a fuzzy version is specified, e.g., Using foo/bar@1.0.2 CCI-I-765

Add a feature that allows the following : The ability to generate API token that is solely for orb management. The Api token is only able to be used to publish new orb versions in our organization's namespace and no other permissions. CCI-I-1509