Please rename the heading "Releases" to "Deployments" within Jira. We are trying the CircleCI JIRA integration. It is showing CircleCI Deployment data within an individual JIRA ticket, on the right hand side of the JIRA Ticket. This information is shown under the title "Releases", but I think it should be "Deployments", as per DevOps convention. These may be Deployments to non-production environments, and doesn't account for when we use Feature Flag tools to Release software. Also, when you actually click on the Releases info, it brings you to a menu titled "Deployments"!

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

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

I have a few workflows where we evaluate a branch for changed paths and do a circleci step halt if there are no hits. This works well enough, but the issue is that in the UI the job containing step is still marked in green (as is the skipped job). Ideally we would have a halt syntax that allowed recording a success, failure, or new (as far as I can tell) "skipped" state for the jobs that didn't run for a particular invocation (e.g. a PR changeset). CCI-I-1496

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

As a company we often have parts of our build process that must remain private. It would be nice to be able to share configuration through orbs versus copying and pasting YAML from project to project however, we would not want this in the public registry. Is there or can their be support for hosting a private orb registry. If that is not available, offer private namespaces in the current registry? CCI-I-819

Currently we can only "Allow Uncertified Orbs" globally for the whole organisation. It would be useful if we could do it on per-project basis. CCI-I-780

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.

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 would like an API endpoint to fetch all, or a subset of, semantic versions available for a given Orb. My goal is for dependency update tools, such as Renovate, Dependabot, Greenkeeper, etc., to use that API endpoint to fetch a list of available versions for a given Orb so that the tool can update the Orb where it's referenced in Circle CI configuration files. CCI-I-719