timwis / jkan

A lightweight, backend-free open data portal, powered by Jekyll
https://jkan.io
MIT License
219 stars 310 forks source link

Version 2.0 #245

Closed timwis closed 1 year ago

timwis commented 1 year ago

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

Non-breaking changes

Deprecations

Contributors

timwis commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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] commented 1 year ago

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...

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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!

Screenshot 2023-03-30 at 12 04 24

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.