Short version: only about 8% of portals are on the newest patch of a supported branch, and the most common version (2.9) in the wild is already EOL.
If your instance is in the catalog, you can look up what it’s been reporting week to week. If it’s missing or we’ve got it wrong, tell us and we’ll fix it.
And if something’s blocking an upgrade on your side, I’d like to hear what. That’s the part the data can’t tell me.
Looking forward to the upcoming Ecosystem Dashboard where we can see all this great metadata sliced, diced and analyzed at a glance with the latest crawl metadata.
And since it’s time-series, it’d be interesting to see how things change and evolve over time…
Staying current with CKAN will also help limit exposure to security vulnerabilities. Upgrading doesn’t just protect your site - it also helps uphold the reputation of CKAN as a reliable and trustworthy product.
A possible explanation: In many cases, even apparently minor changes lead to breaking changes. I can therefore well understand why operators want to stick with a working version for as long as possible.
It might therefore sometimes be better to update the major version more quickly. Then you can see that it’s not just a security update, but that the functionality is changing as well.
Yeah, exactly. I’d rather not spotlight the version-wise vulnerabilities (even though they’re sitting there in the changelog). Wouldn’t take much for someone to connect the dots
Fair point and also I think it’s the most common one.
It’s worth separating two things though. A major release changes functionality, and tells you so up front. A patch release usually doesn’t, but it’s also where the security fixes land. So “stay put until the next major” quietly means “skip the security patches too,” which probably isn’t the intent. Staying on the newest patch of whatever branch you’re on is usually cheap, and it’s a different decision from a major upgrade.
That said, your point about the major upgrade being the visible one is a good argument for making the path clearer.
The migration tips wiki is genuinely good. 2.11 to 2.12, maintained by @wardi@amercader_2 @smotornyuk from the tech team. There are equivalent pages for 2.10 to 2.11 and 2.9 to 2.10, which matters if you’re a few branches back and chaining through them.
The extension modernization guide is also worth a look if custom extensions are what’s holding you up. It’s experimental, but it’s the closest thing to a checklist.
If the wiki is missing a gotcha you hit, that’s probably the single highest-leverage thing any of us can contribute back. Every operator who solves a breaking change in private solves it again for the next person by writing it down.
I’ve seen a preview and I’m sure it’d be a valuable resource for the community - it’s a much needed signal for site and extension maintainers!
BTW, @TedHabermann you may want to check the ecosystem metadata. Apart from data quality, it might be interesting to take into account the platform metadata as well?
Are the extensions more/less of a problem than versions? I see there are 1000+ extensions. How many of those modify the underlying data model? I think I am most interested in the scheming* extensions. From a quick 30,000 ft look, they definitely modify the model. Is this where we would add, for example, ORCIDs for people or RORs for organizations? If yes, I would focus on getting those extensions into core and trying to extoll their benefits. Right now it looks like 48 instances are using scheming-orgs, less than 10%. I don’t see scheming_people… Is there a reason for that?
Scheming is widely deployed @TedHabermann . FYI, we’ll start cataloguing schemas in the EC in the near future - not just dataset schemas, but table schemas as well! Hopefully, in that way, CKAN users can easily reuse them - making crosswalks easier!