Resources

Attendees

Please add yourself to the list of attendees.

Agenda & Notes

        • Starting with v1.11, because that's the VIVO version we took it from.
        • Starting with 1.0 to have a clean start.
        • Starting with a completely different semantic versioning number.
        • Using release dates like v2023-06-12
        • maybe a lot more. Inspire us!
      2. Philip: My fav --> Using release dates like v2023-06-12
        Unless you work out a clear definition schema for what is a major, minor or patch change, then semver.
        When using good GH PR titles and PRs don't change unrelated things at the same time, auto changelog when doing a release is enough, imho
      3. Melanie:
        • In favor of dates, not easy to decide for definitions for changes
        • Clear definition/documentation would be needed for SemVer
        • MODS defines major change (new version) as one that is not backwards compatible; changes that do not break existing implementations are considered minor
      4. Javed: Release dates etc separately as metadate, using SemVer. Approach: Definition of major, minor, patch is how it affects the consumption of the Ontology
        • major is when previous version is not compatible (deleting class )
        • minor (additive, is legacy SPARQL etc. still working...)
        • patch (typo, adding a description, Readme fixes etc. → no semantic impact)
      5. Brian: Semantic Versioning
        • List of releases, better overview about what's current
        • would be easier for consumption → if only patch release, no worries about integrating it in a running system
        • Versioning should be orthogonal to VIVO versioning, starting with a higher number than being used currently in VIVO versioning
      6. Tatiana
        • tendency to dates, but semver makes it easy to be aware of major changes (and history, persons / reasons behind it)
      7. Georgy
        • Agrees, SemVer is the way to go
      8. Dragan
        • Software developers will agree with SemVer
        • There are different perspectives, but taking into account that the VIVO Ontology is being used in VIVO, SemVer would make assessment easier
        • SemVer has more information in the name
      9. VOTE: It will be SemVer
      10. Which number to choose
        • 1.11 because it's the version it comes from
        • 1.14 because it's the current VIVO version
        • 1.0 would suggest it's already outdated
        • 2.0 suggest it's already ahead
        • Another approach: Take a number to a higher number to have some buffer and to get people to get used to the idea of separate releases (like 2.0 will be confusing, too)
        • If higher number: Where are the lower numbers?
        • Documentation is key, independent of the solution
        • Latest release in https://lov.linkeddata.es/dataset/lov/vocabs/vivo is 1.6
        • Major changes will be collected and a release schedule has to be developed
        • Deprecation process has to be used, too
      11. VOTE:
        1. We will use Version 1.7.0 as the first release with the status quo in the repo. Then SemVer will apply.
        2. VOTE accepted
      12. Maven release
        1. maven configuration in pom files could be copied from ORCID client API project - https://github.com/vivo-project/orcid-api-client/blob/main/pom.xml
        2. has to be discussed in detail
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.