Versions Compared

Old Version 1

changes.mady.by.user Jon Corson-Rikert

Saved on

compared with

New Version 2

changes.mady.by.user Jon Corson-Rikert

Saved on

Key

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

First cut reflection of work in progress for the upcoming VIVO 1.8 release

Projected Release Timing

One outcome of the meeting of VIVO sponsors at the March, 2014 DuraSpace Summit even in Washington was a request to move to a regular release schedule where timing would be predictable and the determination of features included in each release – if a feature was deemed to be ready, it would be included; otherwise, it would wait until the next release.

A schedule of two releases per year targets a May code freeze for a June release (VIVO 1.7), and a November code freeze for December release.

The VIVO 1.8 release is being delayed to allow completion of a task that has been deemed essential for moving the VIVO project from incubator to full project status – replacement of the Pellet reasoner (VIVO-778).

Release Mechanics

The VIVO project uses the DuraSpace JIRA issue tracking system to manage issues and time tracking leading up to any given release.  Issues are categorized as bug fixes, tasks, code tasks, or improvements, grouped into components such as ontology or testing or technical debt, and assigned a status based on criticality to the release.

View unresolved and recently-modified issues for the v1.8 release. Note that issues are typically written as specifically as possible to provide clear requirements to developers and allow for realistic time tracking; when it makes sense, more detailed tasks are grouped as sub-tasks of a more general summary task.

When all issues marked with a status of blocker have been resolved, a code freeze is declared and a release candidate is prepared to allow Selenium (acceptance) testing to begin. Most releases include require several iterations of release candidates and testing to address problems detected in testing.

These items are taken from descriptions of Git commits and JIRA issues:

  • Modularization
    • Major pieces of the application are selected at startup, based on a configuration file.
  • Improvements in display
  • Model handling
    • Technical debt: all access of triples goes through two parallel sets of channels (content and configuration).
  • Editing faux properties (VIVO-774)
  • Schema.org integration from Colorado (VIVO-928)
  • Wiki restructuring
  • Customization guide

...