Closed timwis closed 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?
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.
@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!
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.
@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 😬
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).
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
.
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
3.1.2
, and upgrade ruby and JavaScript dependencies to recent versionslicenses.yml
for compatibility with Decap CMS. As a result,site.data.licenses
is nowsite.data.licenses.items
.site.data.categories
is nowsite.dataset_categories
.baseurl
setting from_config.yml
Non-breaking changes
/categories/
index page and a page per categoryDeprecations
Contributors