Learning more about how repository staff evaluate new Dataverse software versions

[Julian Gautier]

Hi everyone,

I'm writing to learn how folks who are considering updating to newer versions of Dataverse review those new versions. 

If you have a process or a set of activities you and your colleagues use to review new versions of the Dataverse software, could you write about them in this email thread? Or maybe attach or link to any documentation that describes what you do?

Please let me know if you have any questions.

All best,

Julian

Julian Gautier (he/him)

Product Research Specialist, IQSS

Interested in helping test Dataverse? Sign up for user experience research

[Seeger, Bethany]

Hi Julian, 

This might be tangential to what you're asking, though I do think it overlaps some.  

This is more "what" we do to review upgrades, rather than "how" we decide if we're going to move forward a version. 

The first thing I do is read the release notes to see what's changed and how much work an upgrade might be. 

We have a dev system that we can try things out on once we decide we want to upgrade. That's the first place that upgrades land and then we look through and test out that system.   I've been working on writing a document that outlines the features to look through when testing.   If all looks good here, then we will consider moving it to our test system. 

We are going to move from 5.14 up to 6.6 soon, via scripts that Oliver B. shared at the community meeting in June. 

I'm now working through reviewing the new features in each release so I can share with our internal group about the changes, broken into categories: user facing changes, web admin facing changes, and devops level changes.  This is very tedious, but I'm not sure how else to do it, to show exactly what's changed only between 5.14 and 6.6.

One thing I recently discovered that was amazingly helpful was the API changelog [1]. That saved me tons of work in discovering API changes.  I will check this before any upgrade we do in the future. 

Hope this helps some, 

Bethany

[1] https://guides.dataverse.org/en/latest/api/changelog.html

---

From: dataverse...@googlegroups.com <dataverse...@googlegroups.com> on behalf of Julian Gautier <julian...@g.harvard.edu>
Sent: Tuesday, September 2, 2025 2:20 PM
To: Dataverse Users Community <dataverse...@googlegroups.com>
Subject: [Dataverse-Users] Learning more about how repository staff evaluate new Dataverse software versions

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dataverse-community/2022bfa1-8092-454e-8f2b-f4eb969ed34an%40googlegroups.com.

[Julian Gautier]

Hi Bethany,

Ah thanks for bringing this up. I was thinking more along the lines of the first thing you mentioned, learning "what" folks do to review upgrades before they upgrade. I'm assuming that the folks doing the reviewing have already decided to upgrade, and are mostly looking to evaluate the quality of the changes, learn how they might configure things that are configurable, and address or mitigate any concerns they have.

So what you shared is really relevant and helpful. Thanks!

[MM - ADA]

Hi Julian.

At ADA, we have a test instance that the ADA devops uses as an initial test to see what might go wrong in an upgrade. It's a pretty bare bones instance and not that complex so nothing usually does go wrong.

Once that test instance has been upgraded and any technical problems identified, the devops upgrades ADA's staging instance which is pretty close to ADA's primary production instance, but not identical.

The ADA team then looks at the release notes to see what optional new functionality is available in the new release.
For any new functionality that is of interest to ADA, a shared spreadsheet is created, the functionality of interest is added as a line, and allocated to the appropriate ADA team member to test it to make sure it works.

Once the list is created, I ask the devops to enable the identified functionality on the newly-upgraded test/staging instance.

For new functionality that is not optional, a line is added to the shared spreadsheet and assigned to an appropriate ADA team member to test it, to ensure it works.

The testing takes place over a week or two based on people's workloads, marking the spreadsheet with P/F and any notes.

Once the testing is complete, I look at any tests that failed and evaluate if we should upgrade ADA's primary production installation or wait for the next release. (We are often 1 release behind the newest, to see if there any bugs identified, and wait for the fix if necessary, then upgrade).

Once everything is deemed ok with the staging installation, the ADA devops upgrades ADA's primary production installation. It is more complex than the staging site so things can still go awry but we upgrade on a Monday or Tuesday evening, so we have the rest of the week to catch anything problematic, rolling back if we have to (although that has been very rare). Ideally everything is re-tested on the production instance, logging issues with the dataverse team for anything that looks like a bug.

I hope that helps... let me know if you want more details on any of the above.

Marina

[Julian Gautier]

Hi Marina,

Thanks so much for sharing. This is helpful!

[Philipp Conzett]

Hi Julian,

At DataverseNO, we currently don't have detailed documentation of how we consider updating to newer versions of Dataverse, but I think the first two steps in our upgrade routine are briefly addressing what you are asking about:

STEP 1: When a new version of the Dataverse software is released, the Head of DataverseNO Repository Management reviews the release notes and decides whether DataverseNO should be upgraded to the new version or not. When in doubt, other members of the repository management are consulted.

STEP 2: Before we start working on an upgrade, the Head of DataverseNO Repository Management and the technical team review the release notes to check whether there are any showstoppers. If there are no showstoppers, we continue with the next step below. If there are showstoppers, we decide whether we want to try to resolve them or whether we want to wait for a later release.

Best,
Philipp