-
Notifications
You must be signed in to change notification settings - Fork 3
Repository checks
This document explains the failures and warnings reported by the review tool regarding the package's repository and how to resolve these.
Failures and warnings are grouped by their type.
Their messages are used as headings and
{} represents a placeholder.
Every package must have a readme that informs users of what they can expect from the package. You should include information on what the package does, how it can be used and any other information you think is useful. For color schemes and themes, screenshots are greatly appreciated.
Package Control requires you to push tags to your repository in order to communicate what should be offered to users. These tags must follow the format of semantic versions.
It's not that you have to follow everything that semantic versions ask for, since they are mostly intended for libraries dependency control, but the format itself is used to determine whether a tag is supposed to be a release or some other random thing that has been tagged for a different reason.
Examples for semantic versions
(note that the optional v prefix is stripped):
- 0.1.0
- 1.0.0
- v1.2.3
- v2.3.4-beta.1 (not installable by default; see below)
- 2017.1.2
Examples that are not semantic versions:
- 0.1
- 1.0
- 1.0.0.0
A tag is a named reference to a blob (commit) in your git history. Creating (and pushing) a semantic version tag equals to making a release.
You usually make a release
from your main branch
when you consider your repository
in a state mature enough
to be consumed by users.
For an initial release,
the versions 1.0.0 or 0.1.0
could be appropriate.
We prefix our tags with a v
to indicate that these tags
mark a version of our package.
Package Control will strip
the optional v prefix.
The following commands
will create and push a git tag
from the current HEAD:
$ git tag v1.0.0
$ git push origin v1.0.0Pre-releases are only installable if you explicitly configure Package Control to install pre-release versions of a package. A such, it is usually not a good idea to only host pre-release tags on your repo.
For reference,
check the install_prereleases setting
on PC's settings documentation.