Version 2.0

[timwis]

As I was writing the upgrade guide for #244 I started jotting down the release notes, and thought I'd post them in a draft PR since we're close to being able to release anyway. Here's what I have so far. Let me know if I've missed anything.

Breaking changes

• Upgraded ruby version to 3.1.2, and upgrade ruby and JavaScript dependencies to recent versions
• Replaced built-in editing UI with Decap CMS (formerly known as Netlify CMS)
• Restructured licenses.yml for compatibility with Decap CMS. As a result, site.data.licenses is now site.data.licenses.items.
• Split categories.yml into collection (directory of files). As a result, site.data.categories is now site.dataset_categories.
• Added out-of-the-box config for hosting on Netlify
• Added GitHub Actions workflow for publishing to GitHub Pages
• Removed default baseurl setting from _config.yml
• Switched to parcel for JavaScript bundling instead of Webpack
• Upgraded to Bootstrap v5, which means bootswatch themes no longer work

Non-breaking changes

• Added support for uploading category and organization images
• Ensured the site works without JavaScript
• Added a /categories/ index page and a page per category
• Added a homepage hero image

Deprecations

• We now recommend hosting JKAN on Netlify, but still support GitHub Pages and other static hosting providers.
• If you use GitHub Pages, you'll need to switch on GitHub Actions in your repository to replace the legacy publishing workflow.

Contributors

• dracos
• bryanquigley
• lukemckinstry
• lydiascarf
• timwis

[timwis]

Okay @BryanQuigley @lydiascarf, once the remaining pull requests are reviewed and merged, I think we're about ready to release version 2. Do either of you have some time this week to review?

The only other thing I can think of would be a UI refresh, as it looks a bit outdated, and the look is of course everyone's first impression. I believe Azavea are doing some work around the design for OpenDataPhilly - is there anything we can do upstream to make that easier or benefit from the work?

[BryanQuigley]

Hi Tim!

Thanks for all your work on JKAN!

Azavea just joined https://element84.com/ so things are changing a bit here. I just asked if we can do some UI review.

I'm not sure we need to sync v2 back to gh-pages. They can stand on their own branches and we can just make v2 the default. This is especially true because the gh-pages branch name is just a hold over from the old way to deploy.

The release notes look good to me. @lydiascarf is working on some local development instructions to add as well (the docker ones I wrote early are broken). We also plan to be getting an OpenDataPhilly test site up soon.

[lydiascarf]

@timwis #254 fixes docker compose and gets us off of the infrequently maintained jekyll docker images. Could you please review and add this to the release notes? Otherwise, they look good to me!

[netlify[bot]]

✅ Deploy Preview for jkan-demo ready!

Name	Link
🔨 Latest commit	758556e03b46442dce7cadfe59119433e8e6cc2c
🔍 Latest deploy log	https://app.netlify.com/sites/jkan-demo/deploys/64256a8e4f9e810007ba8c0c
😎 Deploy Preview	https://deploy-preview-245--jkan-demo.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[timwis]

@BryanQuigley Interesting point about not merging the branches... Although, would there be much benefit in leaving v1 around as an active branch? I don't think we want to support it, so if it's just for posterity, perhaps a tag in the git history could suffice? 🤔

Also, I'd love if we could name the default branch main (instead of gh-pages or v2). Simple enough to rename v2 to main, and make it the repo's default branch, but the tricky thing is that I'm not sure how forks and cross-fork PRs would work if we change the default branch 😬

[BryanQuigley]

Good point, just a git tag is enough - and I do agree main name is nicer...

We had to break our fork connection (or else PRs against ODP would try to be against JKAN by default) so the naming doesn't really matter for ODP. Currently working on a plan for how to keep better synced with JKAN (current plan is just rebasing regularly).

[timwis]

but the tricky thing is that I'm not sure how forks and cross-fork PRs would work if we change the default branch 😬

I've just created a new repository to test this out. I forked it from another user account, then changed the name of the default branch in the upstream repository. I went back to my fork, as the other user, and GitHub was clever enough to flag it to me!

Even better, the "Sync fork" button still works, despite the upstream and downstream repos having two different branch names.

Well done, GitHub!

I'll just update the release notes and merge this into gh-pages, then tag it as a release, and rename the branch to main.