Page History

...

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 versionany available version but will be always be put at the end of the version history (it will be the latest)
• Only one in-progress version can exist at any time. When When new version has been created and still needs to pass certain steps of the workflow, it is temporarily 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 and eventually the original submitter can create new versions of an item from the Item View page. By default the original submitter is not allowed to create new version but the permission can be granted with the following property

 versioning.submitterCanCreateNewVersion=false

1. Click "Create a new version" from the Context Menu in the navigation bar.the buttons on the right side of the item page.             Image Added
2. Provide the reason for creating a new version that will lateron later on be stored and displayed in the version summary.
   Image Removed
   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 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.
   Image Removed
    Image Added

After the submission steps and the execution of subsequent workflow steps, the new version becomes available in the repository.

Versions can be also managed via the edit item page, in the dedicated versions tab

Image Added

View the history and older versions of an item

An overview of the version history, including links to older versions of an item, is available at the bottom of an Item View page. The repository administrator can decide whether the version history should be available to all users or restricted to administrators. Since DSpace 6 the repository administrator can decide whether all users should be able to see the version submitter/editor or if this information is restricted and can be seen by administrators only. As this may expose data that my be considered personal (name and email address of the submitter), we encourage everyone to leave the default setting and reveal those information to administrators only.

Image RemovedImage Added

Architecture

Versioning model

...

Persistent Identifiers are used to address Items within DSpace. The handle system is deeply integrated within DSpace, but since version 4 DSpace can also mint DOIs. DSpace 4 and 5 supported one type of versioned handle: The initial version of an Item got a handle, e.g. 10673/100. This handle was called the canonical one. When a newer version was created, the canonical handle was moved to identify the newest version. The previously newest version got a new handle build out of the canonical handle extended by a dot and the version number. In the image below you see a version history of an item using this handle strategy.Image Removed

The canonical handle will always point to the newest version of an Item. This makes sense if you hide the version history. Normal users won't be able to find older versions and will always see just the newest one. Please keep in mind, that older versions can be accessed by "guessing" the versioned Handle if you do not remove the read policies manually. The downside of this identifier strategy is that there is no permanent handle to cite the currently newest version, as it will get a new Handle when a newer version is created.

With DSpace 6 versioned DOIs (using DataCite as DOI registration agency) were added  and the default versioned Handle strategy was changed. Starting with DSpace 6 the VersionedHandleIdentifierProvider creates a handle for the first version of an item. Every newer version gets the same handle extended by a dot and the version number. To stay by the example from above, the first version of an Item gets the Handle 10673/100, the second version 10673/100.2, the third version 10673.3 and so on. This strategy has the downside that there is no handle pointing always to the newest version. But each version gets an identifier that can be use to cite exactly this version. If page numbers changes in newer editions the old citations stay valid. This strategy makes sense especially if you present the version history to all users. In the image below you see a version history using this strategy.Image Removed

In DSpace 4 and 5 only the strategy using canonical handles (one handle that always points to the newest version) were implemented. In DSpace 6 the strategy of creating a new handle for each version was implemented. With DSpace 6 this new strategy become the default. The strategy using canonical handle still exists in DSpace but you have to enable the VersionedHandleIdentifierWithCanonicalHandles in the file [dspace]/config/spring/api/identifier-serice.xml. With DSpace 6 versioned DOIs were introduced using the strategy that every new version gets a new DOI (extended by a dot and the version numbers for versions >= 2). To use versioned Handle you have to enable DOIs, you have to use DataCite as registration agency and you have to enable the VersionedDOIIdentifierProvider in the named configuration file.

...

Version History Visibility

...

By default, all users will be able to see the version history. To ensure that only administrators can see the Version History, enable versioning.item.history.view.admin in the [dspace]/config/modules/versioning.cfg OR in your local.cfg file.

...

Item Level Versioning has a substantial conceptual impact on many DSpace features. Therefore it has been accepted into DSpace as an optional feature. Following challenges have been identified in the current implementation. As an early adopter of the Item Level Versioning feature, your input is greatly appreciated on any of these.

...

There is currently no configuration option to allow submitters to create new versions of an item. This functionality is restricted to Administrators and Collection/Community Administrators. In a context where original submission of DSpace items is done by non-administrator users, it might also make sense to allow them to create new versions. Especially given the fact that new versions have to pass through the workflow anyway.

Conceptual compatibility with Embargo

...

The version history is added on the bottom of a versioned item page. A repository administrator can either decide to show this to all users, or restrict it to admins only. If it is shown to admins only, an end user will have no way to find the way to an older version. Since DSpace 6 you can also configure if the submitter's name and email address should be part of the version history or if they should be hidden. To show the submitter might actually be useful if the editor account is always a generic institutional email address, but may conflict with local privacy laws if any personal details are included.

Image RemovedImage Added

Hide Submitter details in version table

...