search

duraspace / pcdm

Portland Common Data Model
http://pcdm.org/models
Apache License 2.0
90 stars 11 forks source link

Release process #51

Closed ruebot closed 8 years ago

ruebot commented 8 years ago

Determine and document when and how to do a release.

See discussion on #50, specially https://github.com/duraspace/pcdm/pull/50#issuecomment-211630172 and below.

awoods commented 8 years ago

I think it would be initially valuable to have common agreement on the frequency of releases:

  1. After every commit?
  2. After a critical mass of commits or a significant commit?

If we go with option 2, should we target quarterly? biannually? other? with a process for invoking impromptu releases?

tpendragon commented 8 years ago

"Releases" should probably be numbered, semantically, although it pains me to say it.

awoods commented 8 years ago

Currently, releases are indicated by their date, such as: https://github.com/duraspace/pcdm/blob/2ecbbf47cc679737eef4ccce6ca99b32d5b1ccbc/models.rdf#L19

And associated URI: http://pcdm.org/2015/09/28/models

@tpendragon, are you suggesting something else?

acoburn commented 8 years ago

We currently use the date as a means for distinguishing between versions. The W3C document describing best practices for publishing RDF suggests using either date or some form of semantic versioning.

http://www.w3.org/TR/swbp-vocab-pub/

Given that pcdm vocabularies are already using the date convention, I'd be -1 (as a non committer) for changing it, unless there was a really compelling reason to do so.

no-reply commented 8 years ago

A key publication on the issue of ontology versioning is: https://files.ifi.uzh.ch/ddis/iswc_archive/iswc/ih/SWWS-2001/program/full/paper56a.pdf

I'm not sure we should adopt anything like what they suggest, but it's worth a read for the fairly rigorous accounting of cases where forward and/or backward compatibility for terminology is maintained.

azaroth42 commented 8 years ago

@no-reply: TLDR version?

no-reply commented 8 years ago

@no-reply: TLDR version?

Presented (hopefully) faithfully, avoiding personal interpretation:

Ontology changes are motivated by:

  1. changes in the underlying domain;
  2. changes in the shared conceptualization of the user community;
  3. changes to the spec (e.g. changes to abstract syntax).

Changes impact:

  1. instance data;
  2. related ontologies;
  3. related applications.

Backward compatible revisions can be considered as those for which interpretations of data using the previous version are correct. Prospective use (of the ontology) is possible; e.g. simple addition of a class is always backward compatible.

Forward ("upward" in the text) compatible revisions can be considered as those for which interpretations based on the old version of the ontology are correct against data using the new version. Retrospective use is possible; e.g. simple removal of a class is always forward compatible.

Fully compatible and incompatible revisions are those for which both or neither of these hold (respectively). An example of a fully compatible revision is one in which there is a non-lossy revision of the abstract syntax (e.g. RDF 1.0 to 1.1, for most ontologies).

There are (counter-intuitively) cases where an unannounced change leads to better results for instance data than if revisions are announced, but the relationship between the versions is un/under-specified.

A versioning scheme should aim to:

  1. Provide unambiguous reference for every use of a concept (identification);
  2. Make explicit the relation between versions of a concept (change specification);
  3. Provide transparent translation between instance data (transparent evolution).

Identification is served by:

Change specification and evolution are served by:

no-reply commented 8 years ago

And now some of my own commentary:

I'm not sure, given actual practice, that it's reasonable to expect software to infer compatibility of any sort based on version number or namespace contents. In RightsStatements.org, we opted for opaque version numbers (1.0, etc.., but with no guarantees about the weight or meaning of the "major/minor" portions). I think I stand by that decision.

Some of the details of compatibility depend on the commitments of the ontology, instance data, and applications. It's likely worth considering what can safely be considered forward/backward compatible changes for us as publishers of PCDM.

Likewise, it's not immediately obvious how often (if ever) we'll be in a position to publish backward compatible changes, or whether "transparent evolution" is achievable for the kinds of updates we will typically encounter.

In any case, my sense is that all of this points to some release process beyond just merging to master and bumping the modified date. What that should be... /shrug.

escowles commented 8 years ago

IMHO, updates have been pretty infrequent (see https://github.com/duraspace/pcdm/commits/master/models.rdf), and we can just release after every commit.

ruebot commented 8 years ago

@escowles I agree, and that's basically what we have been doing. Especially since we don't have really have another option on the table now.

In any case, my sense is that all of this points to some release process beyond just merging to master and bumping the modified date. What that should be... /shrug.

no-reply commented 8 years ago

Rolling releases are definitely better than no releases.

awoods commented 8 years ago

I am happy to release the updates to the PCDM ontologies since their last, respective, releases: http://pcdm.org/

Are there any on that list that should not be released?

On a related note, we should probably have regular, scheduled PCDM committer calls for general base-touching and housekeeping... quarterly?

ruebot commented 8 years ago

On a related note, we should probably have regular, scheduled PCDM committer calls for general base-touching and housekeeping

:+1: Quarterly or monthly is fine by me.

escowles commented 8 years ago

@awoods I don't know of any ontologies that shouldn't be released. And I agree that we should have a regular call to keep in touch and keep things moving.

awoods commented 8 years ago

There do not appear to be any substantive updates to:

I propose we only release:

..pending: https://github.com/duraspace/pcdm/pull/64

ruebot commented 8 years ago

@duraspace/pdcm-committers see above about meeting.

awoods commented 8 years ago

models has been published from: https://github.com/duraspace/pcdm/commit/d7464e541484f68f2213ab6e676de837bc44fd71

http://pcdm.org/models -> http://pcdm.org/2016/04/18/models