JetBrains Marketplace Help

Versioning of paid plugins

We would like to be as flexible as possible with respect to the versioning models our plugin authors employ, and we don't intend to lock you into ours. We have, however, implemented a few constraints that are designed to unify the versioning models and prevent issues that may arise from non-standard versioning schemes and licensing mechanisms.

To make it easier for you to keep your versioning consistent with our guidelines, we’d like to tell you more about how the releases of our products – and many plugins – are versioned.

There are two versioning parameters that you should be aware of:

  • release-version – the major version, which is closely related to the licensing model

  • version – the build number that is used by the IDE and JetBrains Marketplace

Release-version vs. Version

We use the version parameter to identify the latest update of the plugin that is compatible with your IDE, which allows us to suggest installing the appropriate version. Keep in mind that SemVer (Semantic Versioning) is turned on by default for all new plugins. For more information see Semantic Versioning.

In addition to the version parameter, the changes you make for paid plugins specifically introduces the release-version parameter, which pertains to the licensing of paid plugins. It identifies what is considered to be a major release, and it is tied to the release-date. For example:

<product-descriptor code="PTESTPLUGIN" release-date="20210818" release-version="20211"/> <version>2021.1.1</version>

This example can be considered our initial plugin upload, so it is labeled as a major release. When we upload any minor updates, we keep the release-version untouched and only increment the version:

<product-descriptor code="PTESTPLUGIN" release-date="20210818" release-version="20211"/> <version>2021.1.2</version>

Release-version constraints

Your release-version must meet the following conditions:

  • It must be an integer (dots or other special symbols are allowed but will be ignored).

  • Each release-version must be greater than the previous one (they can't be descending).

  • It must contain at least 2 digits, as it will be split into 2 numbers, the second of which will contain only one digit. If, for example, release-version=20211, the first number would be 2021 and the second number would be 1.

  • The first 2 digits of release-version must match with the version parameter, like release-version=20211 and version=2021.1.1.

Obviously, our intention is not to limit your versioning scheme to the YYYY.R format. Feel free to use the system that works best for you. Please just make sure it meets release-version conditions described above.

Even though the difference between the release-version and version parameters might initially seem a bit complex, we hope this article sheds some light on how to manage them successfully. If you still have any questions about these parameters or versioning in general, do not hesitate to contact us at

Last modified: 04 April 2024