search

SEMICeu / DCAT-AP

This is the issue tracker for the maintenance of DCAT-AP
https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe
72 stars 24 forks source link

Use GitHub releases as intended #56

Closed sandervd closed 1 year ago

sandervd commented 5 years ago

Releases are now committed into a folder in the repository. However, since git is a version control system that has releases as a first class citizen, it would be more appropriate to use those instead.

bertvannuffelen commented 5 years ago

I am not so sure if git releases are the way to go. The problem is that the git tagging/branching not necessarily correspond to the document status. E.g. if your name is misspelled as author, then this is an editorial correction, not a change in the "release" of the standard. According to a strict source control view this correction requires a minor release.

I'm currently involved setting up repositories for standardization documents in git. It turns out that we cannot come up with a fools proof approach solely applying the github source control semantics. We are forced to introduce an additional layer on top of it in order to get the desired way of working, to get the best of both worlds: a unique pinpointing of the published state to a commit, but also an end-user perspective which does not care if the color of the page has changed.

Given the size of this repo, I am quite fine with the current approach.

sandervd commented 5 years ago

According to a strict source control view this correction requires a minor release.

I would tend to disagree; If semantic versioning (3 versioning levels instead of two) were applied for a standard, changing the author name would be at the patch level, clearly indicating that a 'bug' has been fixed, and clearly indicating that the standard hasn't changed. Semantic versioning would have another benefit in the case of data exchange: two systems communicate with the same major version of a specification would by definition be compatible. The current versioning strategy isn't very clear: Is DCAT-AP 1.2 backwards compatible with DCAT-AP 1.1? Do you thing the introduction of semantic versioning, like in software, would cover all cases? https://semver.org/

addragan commented 4 years ago

Proposed resolution: Proposal to use GitHub for versioning control without creating separate folders for each release.

bertvannuffelen commented 4 years ago

best to align the process for all semic managed specifications. Will be part of a more global approach.

sandervd commented 4 years ago

I wrote a small script that could be the start of this discussion: https://github.com/sandervd/DCAT-AP--refactor/blob/master/rewrite.sh

I pushed the result to this repo so that you can have a look without running the script: https://github.com/sandervd/DCAT-AP

bertvannuffelen commented 1 year ago

We keep the current way of working where all releases can be found at the same time. Essentially we are using the repository to host a collection of (html) specifications that are accessible over github pages. So this repository is more a flavor of a static website than a software project.