To ensure we’re providing improvements and fixes without breaking your downstream processes, Stitch versions its integrations. This allows you to understand what’s coming and make any necessary changes before you decide to upgrade.
In this guide, we’ll cover:
Understand integration versioning in Stitch
In this section, we’ll cover:
Version numbers
PostgreSQL (v1)
doesn’t mean Stitch only supports version 1 of PostgreSQL - it’s just referring to Stitch’s version of a PostgreSQL connection.
If you’ve previously checked an integration’s version, you might’ve noticed that version numbers in Stitch and what we have in the docs look a little different.
In the docs, we only use the major version identifier when referring to an integration’s version. For example: You might see 1.0.8
in Stitch, but in the docs we’ll use 1
(or v1
) to refer to the version. Check out the next section for an example.
Note: For some integrations, you’ll see a version that’s formatted like a date, such as v15-10-2015
. These are legacy versions that pre-date the Singer framework and indicate that an integration isn’t backed by a Singer tap. Refer to the Legacy integration versions section for more info.
Version upgrades
Most of the time, you’ll only need to upgrade an integration’s version when we release a new major version. Minor versions and patches are typically applied automatically.
When a new major version is made generally available (or Released, as noted in the next section), a few things will happen:
- The preceeding version is removed from Stitch. New connections can only be created using the new version, but existing connections will continue to run.
- We’ll communicate a deprecation date for the preceeding version, at which point Stitch will no longer offer support for it.
- After a period of time, we’ll communicate a sunset date for the preceeding version. Integrations using the now-sunset version will stop running.
Upgrading to a new major version requires you to re-create the integration in your account and re-replicate historical data.
Note: If you delete the original integration and re-use its namespace (schema name), the re-replication will count towards your row usage. However, if you use a new namespace, the first seven days of replication will be subject to the free historical data load and not count towards your usage.
Version statuses
The following table describes each of the statuses an integration version can be in at a given time:
- Name: The name of the status. Note: We use these status names mainly in the Stitch Docs - only versions in
beta
will have abeta
flag in Stitch. - Status in API: The
pipeline_state
value the status corresponds to in the API. Contained in adetails
object, thepipeline_state
attribute indicates the current version status of an integration. - Availability: Indicates the availability of the version in Stitch or the API:
- Unavailable: The version isn’t available. New connections can’t be created.
- Private: The version is available only to accounts who have been granted access.
- Available: The version is generally available, depending on the plan type required for the integration. For example: If an integration is Advanced or Premium, only users of these plans will have access to it.
- Description: A description of the status, including in-app and support availability
Name | Status(es) in API | Availability | Description |
Alpha |
alpha/beta
|
Private |
|
Beta |
beta
|
Available |
|
Released |
released
|
Available |
|
Released (Testing) |
released
|
Available |
|
Deprecated |
deprecated
|
Unavailable |
|
Sunset |
deprecated
|
Unavailable |
|
Identify an integration's version
To ensure you’re viewing the documentation for the correct version of your integration, you should first check its version in Stitch.
- Sign into your Stitch account.
- On the Stitch Dashboard page, click the integration you want to check.
- Click the Extraction Logs tab:
- If you see No logs available for this integration yet., the version of the integration doesn’t support the Extraction Logs feature. Refer to the Legacy integration versions section below for more info.
-
If you see a list of Extraction Logs:
Open the most recent set of logs and look at the first line:
The string following
tap-<name> version
is the version of the integration you’re using. In this example, that’s1.0.8
, which corresponds to v1.Note: Only major version identifiers are reflected in integration documentation, i.e.
1
versus1.0.8
.
Legacy integration versions
The integrations in the table below only have a single running version, which is listed in the table. When and if these integrations are converted to Singer taps, they will support Extraction Logs and you’ll be able to identify their version using the method above.
Integration | Version | Release date |
Related | Troubleshooting |
|
Questions? Feedback?
Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.