Page History

...

1. What should be Versionable
   
   1. Versioning happens at the level of an Individual Item
   2. Versioning should preserve the current state of metadata, bitstreams and resource policies attached to the item.
2. Access, Search and Discovery
   
   1. Only the most recent version of an item is available via the search interface
   2. Previous versions of Items should continue to be visible, citable and accessible 
   3. The Bitstreams for previous versions are retained. If something was once retrievable, it should always be retrievable.
3. Identifiers
   
   1. Each version of an Item is represented by a separate "versioned" identifier
   2. A base "versionhistory" Identifier points to the most recent version of the Item. 
   3. A revision identifier also exists that is unique to the specific version.
   4. When a new version of an Item is deposited, a new revision identifier will be created.
4. Presentation
   
   1. On the item page, there is a link to view previous/subsequent versions.
   2. By examining the metadata or identifiers, it is possible to determine whether an item is the most recent version, the original version, or an intermediate version.
5. Access Control and Rights
   
   1. Certain roles should be able to generate a new version of the item via submission.
   2. To submitters, collection manager, administrators will be given to option to create new version of an  item.
   3. Rights to access a specific Item should transmute as well to previous versions
   4. Rights to access a specific Bitstream should also transmute to previous versions.
6. Data Integrity
   
   1. The relationships between versions should not be brittle and breakable by manipulating Item metadata records.
   2. The relationships between versions should be preserved and predictable in various Metadata Exports (OAI, Packagers, ItemExport)
   3. The relationships between versions should be maintained in SWORD, LNI and AIP packaging and be maintained in updates and restorations.

User Interface

Creating a new version of an item

Administrators and collection/community administrators can create new versions of an item from the Item View page.

General behaviour: Linear Versioning

From the user interface, DSpace offers linear versioning. As opposed to hierarchical versioning, linear version has following properties:

• A new version can only be created started from the latest available version
• When new version has been created and still needs to pass certain steps of the workflow, it is temporary impossible to create another new version until the workflow steps are finished and the new version has replaced the previous one.

Creating a new version of an item

Administrators and collection/community administrators can create new versions of an item from the Item View page.

1. Click "Create a new version" from the Context Menu in the navigation bar.
2. Provide the reason for creating a new version that will lateron be stored and displayed in the version summary.
   
   Image Added
   
   
3. Your new version is now creates as a new Item in your Workspace. It requires you to go through the submission and workflow steps like you would do for a normal, new submission to the
4. Click "Create a new version" from the Context Menu in the navigation bar.
5. Provide the reason for creating a new version that will lateron be stored and displayed in the version summary.
   Image Removed
   Your new version is now creates as a new Item in your Workspace. It requires you to go through the submission and workflow steps like you would do for a normal, new submission to the collection. The rationale behind this is that if you are adding new files or metadata, you will also need to accept the license for them. In addition to this, the versioning functionality does not bypass any quality control embedded in the workflow steps.
   
    

...

[dspace_installation_dir]/config/spring/api/versioning-service.xml

In this file, you can determine specify which metadata fields are being reset automatically "reset" (i.e. cleared out) during the creation of a new item version.  By default, all metadata fields values (and bitstreams are replicated) are copied over to the newly created version, with the exception of dc.date.accessioned and dc.description.provenance..provenance.  You may specify additional metadata fields to reset by adding them to the "ignoredMetadataFields" property in the "versioning-service.xml" file:

<!-- Default Item Versioning Provider, defines behavior for replicating
     Item, Metadata, Budles and Bitstreams. Autowired at this time. -->
<bean class="org.dspace.versioning.DefaultItemVersionProvider">
    <property name="ignoredMetadataFields">
         <set>
            <value>dc.date.accessioned</value>
            <value>dc.description.provenance</value>
         </set>
    </property>
</bean>

Identifier Service Override

...

You can join the discussion or contribute a new code here:
JIRA DS-1349 - Item Level Versioning exposes personal data 

Credits

The initial contribution of Item Level Versioning to DSpace 3.0 was implemented by @mire with kind support from:

• MBLWHOI Library
• Woods Hole Oceanographic Institution
• Marine Biology Laboratory, Center for Library and Informatics, History and Philosophy of Science program
• Arizona State University, Center for Biology and Society
• Dryad