Versioning of data

[perlpunk]

The current plan is:

• We keep adding commits to the data branch for development
• If we think it is worth to make a release, we create a version number v1.2.3
  • We tag master with v1.2.3
  • We create an orphaned data branch called data-1.2.3 with one commit from current data
  • The data branch will be squashed to one commit, and we start adding commits to it again

TODOs

• [ ] Make sure when adding a commit to data, that the data branch is fetched and rebased to origin
• [x] Include the short commit sha from master into the commit message
• [ ] Write a utility for "tagging" or actually creating data-release branches

[ingydotnet]

I like this plan. Thoughts:

• Use a tag instead of a branch for single commit data thingy.
• Use data-2017-12-04 for tag name
• Remove tags after they are a month old. Maybe leave last 3 tags.

[perlpunk]

• hm. If it's an orphaned tag, it doesn't get fetched with git fetch automatically
• I think we need to keep more releases. Think about libyaml: we are gonna do a clone of a specific branch/tag for automated testing, and as we are all busy, we don't want to have to check that every month or even year.

[ingydotnet]

Let's try tags for now. We can skip the deleting branches idea for now.

[jcfr]

Instead of having data branches, may you could create a release based of master branch and upload a tar.gz containing the generated data ?

[ingydotnet]

I think this is a decent idea.

Anyone can make data from master requiring just the most basic Perl. The tarball can be an alternate method for cave-dwellers. :)

[perlpunk]

There's no need to upload tarfiles if we create tags for the data branch(es). github will do it for us.

[perlpunk]

Commit id from master is now included in data commit message

[jcfr]

Well done @perlpunk