Versions Compared

Old Version 4

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • (30 mins) General Discussion Topics
    1. Features expected for 7.1?
      1. Item Versioning (4Science)
      2. Embargo entire Item (including metadata)  (4Science)
      3. Collection harvested from an OAI-PMH endpoint  (Atmire)
      4. Request a Copy (Mark Wood) – may require UI changes?
      5. Anything else in the works?  Should we consider porting features from DSpace-CRIS to DSpace?
    2. What should happen when you Version an Entity? (Related to https://github.com/DSpace/RestContract/pull/171)
      1. Obviously, the new version must keep the same Entity type.
      2. Does the new version keep relationships to other Entities? Do Relationships get duplicated to the new Version?  Or perhaps are Relationships somehow auto-updated to point at the latest version of an Entity?
      Features expected for 7.1?
      1. Item Versioning (4Science)
      2. Embargo entire Item (including metadata)  (4Science)
      3. Collection harvested from an OAI-PMH endpoint  (Atmire)
      4. Request a Copy (Mark Wood) – may require UI changes?
      5. Anything else in the works?  Should we consider porting features from DSpace-CRIS to DSpace?
    3. How do we deal with "breaking changes" to REST API endpoints between 7.0 and 7.1?  (A "breaking change" is one that would require clients to modify their code/behavior in order to use a specific endpoint.)
      1. For removal/breaking changes, deprecate first, then make change in next major release (e.g. 7.0->8.0)?  (This is likely the approach we should take after 7.x is complete.)
      2. For removal/breaking changes, deprecate for one minor release (e.g. 7.0->7.1), then make change in next minor release (e.g. 7.2 may contain breaking changes compared to the 7.0 REST API, as long as they were first deprecated in 7.1).  (This is the compromise approach we discussed specific for 7.x since 7.x is a unique set of releases, as we are allowing new features in every 7.x release)
      3. Do we allow breaking changes at any time & start a CHANGES.md  file in our Rest Contract to document significant API changes between 7.x releases?  (This approach had concerns about discouraging others from building things on our REST API)
    4. (Other Topics?)
  • (30 mins) Planning for next week
    • Review the Backlog Board - Are there any tickets here stuck in the "Triage" column?  We'd like to keep this column as small as possible.
    • Review the 7.1 Project Board - Assign tickets to developers & assign PRs to reviewers.
      • Paid (by DSpace project) developers must keep in mind priority. If new "high" or "medium" priority tickets come in, developers should move effort off of "low" priority tasks.
      • Volunteer developers are allowed to work on tickets regardless of priority, but ideally will review code in priority order.

...