Upgrading

A paid key covers every release dated on or before its maintenance date. Check that date first, then move all three packages to the new release together. If your license has lapsed, pin your package versions so that a deploy never picks up a release your key does not cover.

Before you upgrade, check the release date against your key

1. Find the new release's date in the changelog. Every release is listed with its date.
2. Find your key's maintenance date. It is in the license line the client logs when it is built: after "updates through" for a current key, or after "released after" in a renewal or lapse notice. It is also in client.License.Payload.MaintenanceUntil (see Check the license in your code).
3. If the release date is on or before your maintenance date, your key covers the release. If it is later, Build() throws a LicenseException with that release; renew first, and put the renewed key in place (see A renewed key).

This check applies to paid keys only. With an evaluation key, Build() never throws because of a release's date.

Move the packages together

IntentSharp, IntentSharp.Catalog and IntentSharp.Extensions.AI are released together with one version number. Set every IntentSharp package your projects reference to the same version, then:

• read Breaking changes for the releases between your version and the new one;
• build, and run your tests;
• start the application and look for the license line in the logs, or read client.License.

After a lapse, pin your package versions

When a subscription lapses, you can keep using the releases dated on or before the maintenance date in your last key. A release dated after it does not accept the key: Build() throws a LicenseException.

A floating version can bring in such a release without anyone choosing it. A floating version such as 1.* resolves to the newest matching release at the next restore, and an automated dependency update can raise an exact version for you. The next deploy then starts with that release, and building its client throws.

• Give each IntentSharp package reference an exact version, for example Version="1.0.0-rc.2" rather than Version="1.*". With central package management, set the exact version there.
• If your build restores with a lock file, keep it committed and restore in locked mode, so that a restore cannot change the version.
• Exclude the IntentSharp packages from automated dependency updates, or review those updates against your maintenance date.

A running process is never stopped. The check runs only when a client is built, so an application that is already running keeps working until it is restarted or deployed again.

Limits

The library does not check for new releases or tell you about them, and makes no network call to do so. Read the changelog for what each release adds and changes.