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 new features included only if ready.  Any feature not on target to be finished by the code freeze data would have to be deferred 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 was originally delayed to allow completion of a task that deemed essential for moving the VIVO project from incubator to full project status – replacement of the Pellet reasoner.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

With that work complete before the holiday break, additional performance-related improvements were prioritized for early January:

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

View unresolved and recently-modified issues for the v1.8 release on the VIVO issue tracker.

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.

The issue tracker is publicly viewable but to comment you need to sign up for a user account with DuraSpace.  Accounts are shared between the DuraSpace wiki and issue tracker but the different DuraSpace projects including DSpace, Fedora, and VIVO each have different permission groups for access to project-specific wiki and JIRA spaces.  Send us a note to be added to the VIVO wiki and JIRA spaces.

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 for conducting acceptance testing, primarily with a set of Selenium tests. Most releases include require several iterations of release candidates and testing to address problems detected in testing.

Finding and reviewing JIRA issues

VIVO application code

For the complete list of issues under consideration for VIVO v1.8, view the full, version-specific report in Jira.

VIVO-ISF ontology

Ontology issues for VIVO v1.8 have been managed in 3 places as the community workflow process evolves.

  1. Within the primary DuraSpace VIVO Project JIRA space
  2. In a older, now-deprecated DuraSpace VIVO Ontology JIRA space (a decision was made in 2014 to stop segregating ontology issues specific to VIVO from the main VIVO project JIRA space 
  3. In a tracker on GitHub, where VIVO-specific issues have been tagged with "question"

Documentation

Documentation issues for VIVO v1.8 are managed using the community/documentation component within the primary DuraSpace VIVO Project JIRA space.

Testing

Acceptance tests for VIVO v1.8 are managed using the testing component within the primary DuraSpace VIVO Project JIRA space. Additional issues related to testing be found by searching for "test" among the issues assigned to version 1.8 that may be listed under components such as technical debt or bug fixes.

  • No labels