Versioning Scheme
- Dominant language
- Go
- Stars
- 60
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
In software, we've come to use things like [semver](http://semver.org/) to ensure programs and their dependencies interoperate well.
Problems with this:
- Forcing data publishers/researchers to follow a scheme does not seem fun or fruitful.
- semver focuses on API changes, and does not apply well to data.
Paths:
- Don't enforce anything. See what happens.
This is flexible to "whatever you want to do." This is liable to yield a proliferating mess of "version" schemes. This seems like the worst thing to do.
- Find an existing standard that makes sense and use it.
Are there well established (and _sane_) data versioning standards? I'm not too familiar with what's out there.
- **data semver** (or more researcher-friendly: Semantic Data Versioning), a semver fork tuned for data purposes. Perhaps something like this:
```
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you REMOVE data.
MINOR version when you ADD data in a backwards-compatible manner, and
PATCH version when you CLEAN or REFORMAT data, without ADDING or REMOVING values.
```
Discussion welcome.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.