jbenet / jbenet/data

Versioning Scheme

Open
#13 4 comments 0 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.