Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SWORD: decide if minor version bumps for datasets will be allowed #795

Closed
pdurbin opened this issue Aug 4, 2014 · 7 comments
Closed

SWORD: decide if minor version bumps for datasets will be allowed #795

pdurbin opened this issue Aug 4, 2014 · 7 comments
Assignees

Comments

@pdurbin
Copy link
Member

pdurbin commented Aug 4, 2014

When SWORD was introduced into DVN 3.x datasets only have major versions (1, 2, 3) but now in Dataverse 4.0 datasets can have versions such as 1.1, 2.1, etc.

In the GUI, we allow users to choose between major and minor version bumps but we can't communicate this choice via SWORD.

This ticket is about how SWORD should behave with regard to version bumps. Should it always bump to the next major version? Should it always bump to the next minor version if it can?

@pdurbin pdurbin added this to the In Review - Dataverse 4.0 milestone Aug 4, 2014
@pdurbin pdurbin modified the milestones: Beta 8 - Dataverse 4.0, In Review - Dataverse 4.0 Oct 14, 2014
@pdurbin pdurbin self-assigned this Oct 14, 2014
@pdurbin
Copy link
Member Author

pdurbin commented Oct 20, 2014

#608 (comment) says "We now advance the versions at the publish call." That's for the native API, which is currently documented like this at https://github.com/IQSS/dataverse/tree/master/scripts/api

"Publishes the dataset whose id is passed. The new dataset version number is determined by the most recent version number and the type parameter. Passing type=minor increases the minor version number (2.3 → 2.4). Passing type=major increases the major version number (2.3 → 3.0)."

So no matter what we pick for the SWORD API, people can get more granularity from the native API.

@pdurbin
Copy link
Member Author

pdurbin commented Oct 20, 2014

v1 of the Data Deposit API was shipped with DVN 3.x, which only supported major versions for datasets.

For backward-compatibility, at least for now, we will have v1.1 of the Data Deposit API continue to increment dataset by major version. This has already been implemented, so I'm moving this ticket to QA.

As described above, if API users want more granularity in dataset version bumping, they can use the native API.

@pdurbin pdurbin removed their assignment Oct 20, 2014
@esotiri esotiri self-assigned this Oct 21, 2014
@kcondon kcondon assigned kcondon and unassigned esotiri Oct 24, 2014
@kcondon kcondon assigned esotiri and unassigned kcondon Nov 3, 2014
@eaquigley eaquigley modified the milestones: 4.1, Beta 8 - Dataverse 4.0 Nov 3, 2014
@eaquigley eaquigley assigned pdurbin and unassigned esotiri Nov 3, 2014
@eaquigley
Copy link
Contributor

@pdurbin I discussed this with @mcrosas and we think this is needed but can wait till after 4.0 is completed.

@pdurbin
Copy link
Member Author

pdurbin commented Nov 4, 2014

@eaquigley can you please clarify what you'd like me to do? It's an easy change if you'd prefer minor versions to be favored over major versions in SWORD.

@eaquigley eaquigley modified the milestones: Beta 8 - Dataverse 4.0, 4.1 Nov 4, 2014
@eaquigley
Copy link
Contributor

SWORD API will check for the lowest level of bump it can do, i.e.-if only a metadata change then it would be a minor version bump happens, if a file is changed, a major version bump happens.

@pdurbin
Copy link
Member Author

pdurbin commented Nov 4, 2014

All set. Moving to QA.

@pdurbin pdurbin removed their assignment Nov 4, 2014
@esotiri esotiri self-assigned this Nov 7, 2014
@esotiri
Copy link
Contributor

esotiri commented Nov 7, 2014

Verified major version change after adding file and publishing and minor version editing metadata and publishing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants