Download the PHP package mistralys/changelog-parser without Composer
On this page you can find all versions of the php package mistralys/changelog-parser. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download mistralys/changelog-parser
More information about mistralys/changelog-parser
Files in mistralys/changelog-parser
Package changelog-parser
Short Description PHP library to parse Markdown-formatted change log files.
License MIT
Informations about the package changelog-parser
Changelog Parser
PHP library to parse Markdown-formatted change log files.
Requirements
- PHP >= 7.4
- JSON extension
- Composer
Installation
Add the package to your composer.json
file with the following command:
Also see the Packagist page.
Supported changelog formats
The parser expects all versions to be listed as headers with the same header level, and individual changes to be added as a list. Both of these examples will work:
Version heading formats
All the following headings are valid formats that the parser will recognize:
For more information on the spectrum of version strings that can be used, have a look at the supported formats in the mistralys/version-parser package, which is used to read them.
Nesting the changelog in a document
The way the parser analyzes the Markdown document means that the changelog can be nested anywhere. The heading level will be inferred from the first version heading it encounters.
In this example, the changelog is not a separate document, but is nested in a subsection.
The changelog parser will stick to the first changelog it finds in the document, meaning that only the first of multiple, separate version lists will be used, even if they have the same heading level.
Subheaders within versions
The parser will recognize subheaders within a version entry, and add collect these as plain text to be accessed again later. This makes it possible to further document things like breaking changes for example.
Only the items below the version will be considered changes in the
version. The "Breaking changes" subheader and any additional content
is captured as text, which can be accessed via getFreeformText()
:
This will output:
Categorized changes
Introduction
The parser also supports categorized changes, which are a way to mark changes by type. Entries can be prepended with symbols that define what kind of change they are, with two criticality levels: Optional and mandatory.
The idea is to mark changes that require users to take action with a new version, declare which ones are optional, and categorize them by the components that were modified.
Supported symbols
The parser handles the following symbols:
{ }
- Global change, optional( )
- Global change, mandatory{C}
- Component change, optional(C)
- Component change, mandatory
For component-related changes, the name of the component is expected to come directly after the symbol, and the description of the change separated by a colon.
Example
This version contains three changes, two of which are mandatory, requiring special attention when updating. The third is optional.
Note: Optional changes do not necessarily need to be marked with a symbol, but it has the advantage of using the component name to group changes by component.
Backticks for symbols
To make the changelogs nicer to read, the parser supports using backticks for the symbols. With a monospaced font, they are better aligned and easier to read.
Usage examples
Fetch all versions
Fetch the latest version
Get a version by number
This will throw an exception if the version is not found. To check if a version number exists beforehand
Check if a version exists
Note that this requires the exact version number to be known (major, minor and patch version numbers). For a more flexible way to find versions, the version info is best used instead.
For example, to find all versions matching v4.2.x
:
Go through individual changes in a version
Note the use of the
requireLatestVersion()
method: This will throw an exception instead ofNULL
if no versions are found in the change log. Handy to avoid checking for a null value.
Persisting and caching
To easily store or transmit changelog information, the parser offers the possibility to serialize the data to JSON. This can be decoded again later instead of parsing the source file each time.
This example will automatically create a JSON cache file, which performs better than parsing the source Markdown file each time, especially for large files.
All versions of changelog-parser with dependencies
mistralys/version-parser Version >=2.0
ext-json Version *
php Version >=7.4