Mason-Registry

The Mason registry is a GitHub repository containing a list of versioned manifest files.

The registry structure is a hierarchy as follows:

Bricks/
  Curl/
     1.0.0.toml
     2.0.0.toml
  RecordParser/
     1.0.0.toml
     1.1.0.toml
     1.2.0.toml
  VisualDebug/
     2.2.0.toml
     2.2.1.toml

Each versioned manifest file is identical to the manifest file in the top-level directory of the package repository, with one exception, a URL pointing to the repository and revision in which the version is located.

The 'registry' 0.1.0.toml would include the additional source field:

[brick]
name = "hello_world"
version = "0.1.0"
author = ["Sam Partee <Sam@Partee.com>"]
source = "https://github.com/Spartee/hello_world"

[dependencies]
curl = '1.0.0'

TOML

TOML is the configuration language used to configure projects written in Chapel using Mason. A TOML file contains the necessary information to build a Chapel program using Mason. TOML Spec.

Submit a package

The Mason registry holds the manifest files for packages submitted by users. To contribute a package to the mason-registry you should open a Pull Request to the mason-registry with a TOML file pointing to the published source. For a more detailed description follow the steps listed at https://chapel-lang.org/docs/tools/mason/guide/submitting.html

Once your package is uploaded, maintain the integrity of your package. Please notify the mason-registry maintainers if your package should be taken down.

Namespacing

All packages will exist in a single common namespace with a first-come, first-served policy. It is easier to go to separate namespaces than to roll them back, so this position affords flexibility.

Semantic Versioning

To assist version resolution, the Mason registry will enforce the following conventions:

The format for all versions will be a.b.c.

Major versions are denoted by a. Minor versions are denoted by b. Bug fixes are denoted by c.

• If the major version is 0, no further conventions will be enforced.
• The major version must be advanced if and only if the update causes breaking API changes, such as updated data structures or removed methods and procedures. The minor and bug fix versions will be zeroed out. (ex. 1.13.1 -> 2.0.0)
• The minor version must be advanced if and only if the update adds functionality to the API while maintaining backward compatibility with the current major version. The bug fix version will be zeroed out. (ex. 1.13.1 -> 1.14.0)
• The bug fix must be advanced for any update correcting functionality within a minor revision. (ex. 1.13.1 -> 1.13.2)