# Channels that filter releases and packages

Source: https://www.jawsdeploy.net/changelog/channel-version-rules

A channel can now gate which release versions may be created in it, and which package versions may be pinned into them - so a stable stream and a beta stream can share one project without anyone typing the wrong version.

## What's new

Channels have always been able to send releases down a different lifecycle. Now they can also decide **which versions are allowed in the lane** - both the release version itself, and the package versions pinned into it.

### Release version rules

A channel can carry a **version range** and a **prerelease setting**. The version range is defined as a NuGet-style range e.g. `[2.0,3.0)`. A release can only be created in the channel when its version satisfies both. Set a production channel to *Stable only* and a preview channel to *Prereleases only* and the two streams stop leaking into each other.

The two parts are independent: the range bounds the version **number**, and the prerelease setting decides whether tagged versions are allowed at all. The range's endpoints therefore compare on the number alone, so `[2.0,4.0)` accepts `2.0.0-beta` and rejects `4.0.0-beta`. This deliberately differs from raw NuGet range semantics, which sort a prerelease below its own release - a channel configured as "2.0 to 4.0, betas only" has to accept `2.0.0-beta`.

Prereleases are chosen from a dropdown - *Any version*, *Stable only*, *Prereleases only*, or *Matching a pattern...* for a custom regular expression over the tag. The mode is derived from the stored pattern rather than being a field of its own, so a channel authored over the API displays as the matching preset.

Because a suggested version has no prerelease tag on its own, a channel can also carry a **tag to add to auto-suggested versions**: set it to `beta` and the release form suggests `1.4.0-beta` instead of `1.4.0`.

### Package version rules

Each channel now has an ordered list of package rules: a **package filter** (a glob over the package ID, e.g. `MyApp.*`), plus the same version range and prerelease setting. Rules are matched top to bottom and the **first matching filter wins**, so specific filters go above the catch-all. A package matched by no rule is unconstrained, and each filter may only be used once per channel.

### In the release form

Rules apply while you type, not only on submit. The suggested version is seeded from the releases already in the selected channel and nudged to satisfy its rule; package dropdowns only offer versions the channel allows; switching channel re-pins any package whose version is no longer allowed and tells you what it changed; and if no available version of a package satisfies the rule, you get an explicit error and the create button stays disabled.

The channel editor has a **try a version against this rule** box that reports *Allowed* or *Rejected* with the reason before you save.

### Upgrading

Every rule field is blank after upgrade, so existing channels are unrestricted and nothing changes until you fill one in. Rules gate release *creation* - releases that already exist are unaffected if you tighten a channel later. CI gets the same errors as the UI, naming the channel and the reason.

See the [Channel Version Rules guide](https://www.jawsdeploy.net/guides/channel-version-rules), or the channel endpoints for [create](https://www.jawsdeploy.net/rest-api/project-channel-create) and [update](https://www.jawsdeploy.net/rest-api/project-channel-update).