Download the PHP package mistralys/version-parser without Composer

Version string parser for PHP

PHP utility used to parse application version strings, and retrieve information on the version, as well as convert it to a numeric build number (float or integer). Supports release tags like alpha, beta and reelease candidate, as well as custom branch names.

Supported version strings

The parser expects versions to be in the following format:

MajorVersion.MinorVersion.PatchVersion-BranchOrTag

This allows the use of a wide range of version strings. Some examples:

• 1
• 1.1
• 1.1.5
• 1.145.147
• 1.1.5-rc1
• 1.1.5-beta
• 1.1.5-beta2
• 1.1.5-beta.42
• 1.1.5-BranchName
• 1.1.5-BranchName-alpha2
• 1.1.5 BranchName A2 Spaces are allowed
• 1.1.5 "Branch name" Quotes are stripped
• 1.1.5 (BranchName) / Alpha 2 Special characters are filtered out
• 1.1.5-DEV Branch Name Branch names after the tag type

Most special characters are filtered out, which means that it is very lenient in what is passed to it. After the version number, anything that is not a tag qualifier (beta, alpha, etc.) is considered the branch name.

Installation

Simply require the package with composer.

Via command line:

Via composer.json:

Usage

Getting individual version numbers

Getting a version without tag

The version is normalized to show all three levels, even if they were not specified.

Getting a short version

The method getShortVersion() retrieves a version string with the minimum possible levels.

Getting the full version, normalized

NOTE: The branch name is also normalized. Words are capitalized, and spaces are removed. Other special characters are preserved.

Checking the tag type

To check the release type, the shorthand methods isBeta(), isAlpha(), etc. can be used. See "Supported release tags" for details.

Alternatively, it is possible to check the tag type manually.

The tag info object that can be accessed with the getTagInfo() method goes more in depth.

For example, the method getTagName() will return the tag type exactly as used in the version string, whereas getTagType() will only return the long type variant (e.g. beta instead of b):

Getting the tag number

When no number is added to the tag, it is assumed that it is the tag #1.

With a number added:

Getting the branch name

This also works in combination with a release tag:

Branch names may contain special characters. Quotes are filtered out:

Setting the separator character

By default, the branch name and tag are separated with hyphens (-) when normalizing the version string. This can be adjusted to any character:

Will output:

Converting tag types to uppercase

By default, tag types are converted to lowercase when normalizing the version string. They can be switched to uppercase instead:

Will output:

Supported release tags

The parser will handle the following tags automatically, and assign them a build number value:

• dev or snapshot - Development release, weight: 8
• alpha - Alpha release, weight: 6
• beta - Beta release, weight: 4
• rc - Release candidate, weight: 2
• patch - Patch/bugfix release, weight: 1
• stable - Stable release, weight: 0

This means that comparing the same version numbers with different release tags will work. For example, 1.4-beta is considered a higher version than 1.4-alpha, because beta has a lower weight than alpha.

Numbering tags

Also supported is numbering tagged versions:

• 1.0-alpha - Implied alpha1
• 1.0-alpha2 - Alpha 2

Adding custom tags

If you use other tag types in your application's version strings, they can be added so the parser recognizes them:

If you mix custom tag types and the standard ones, be careful with the sorting weight you set for them, so they will be weighted correctly. If needed, you can change the weight of the default types to make more room.

This for example resets the weights for some existing tag types, and inserts new ones:

NOTE: The weights are used in the generated build numbers. Changing the default tag type weights will change their build numbers as well.

Build numbers

The version strings are intelligently converted to numbers, to allow comparisons and sorting. This includes the release tags like alpha or beta, which are converted as well. The result is a build number which can be either a floating point number, or an integer.

NOTE: These numbers are not meant to be human-readable. Their sole purpose is to recognize version numbers programmatically.

There are two methods related to this:

Sorting versions

The best way to sort versions is to use the build numbers, which allow numeric comparisons. Here's an example that sorts them in ascending order:

This will sort the list the following way:

1. 1.1.0
2. 1.5.9-beta
3. 1.5.9
4. 2.0.0-alpha
5. 2.0.0