Exiting project maintenance mode

[tjex]

Hey all @zk-org/maintainers

As per the maintenance mode plan, it would seem like we're due to exit back into the world of releases 🎉

There is one bug report left, which is my own. But it's to do with zk graph, which is a bit of an 'edge' feature. I think it's acceptable to consider this as a non-critical bug, with regards to cutting a new release or not.

All bug reports over at zk-nvim have also been closed.

We also just got one new bug report about the date parsing issue that we have already fixed.

Are there any concerns or reasons for not looking at cutting zk 0.14.1 as a next step?

It also times nicely to cut the release before sprucing up the docs, as discussed.

[mickael-menu]

That's fine by me. I'll let someone else do the release process to make sure I wrote everything needed in the MAINTAINING.md.

Thanks again @tjex for all your maintenance work!

[tjex]

Yup, I agree. It's good if we work through it ourselves. It'll be a good stress test of the process and documentation. Thanks for writing that up and regarding your thanks, my pleasure! Really happy to be involved.

[tjex]

@mickael-menu ... Am I completely blind / can't use a file search?.. I can't find the MAINTAINING.md doc anymore.

[mickael-menu]

My bad, it was in CONTRIBUTING 😅
https://github.com/zk-org/zk/blob/main/CONTRIBUTING.md#releasing-a-new-version

[mcDevnagh]

Thank you tjex for taking the initiative here! I also propose we elevate you to owner, as you have been spearheading much of the progress in zk

[mickael-menu]

I agree, I changed your role in the zk-org to owner @tjex. Thanks for all the work done so far!

[tjex]

a pleasure 🥳

[tjex]

Draft release is under way. Changelog is done.
Re. builds. I think I can get access to an intel mac to build the binary for it.

If not, do either of you have access to one @mcDevnagh, @jurica or @julio-lopez ?

Also note zk-org/zk-xcompile#3, which we should address for this and subsequent releases.

[jurica]

First off all I'm sorry, I was really busy in the past few weeks and haven't had any time to check what's going on here.
I'm afraid I don't own a Mac anymore, but I remember that go cross compilation with CGO on macOS wasn't really a smooth experience, but IIRC it is possible.
@tjex how did you build the release binaries and source tarballs. I looked into the Makefile and GitHub Actions but can't find anything there. Could you please point me in the right direction or aren't these build on GH Actions?

[tjex]

Not a prob 👍

The builds aren't happening via actions. We need to cross compile with docker (instead of using go's native cross compilation) because we're building with CGO (due to using mattn/go-sqlite3).

The build + tarball commands are here in the makefile

Detail on that and more is in the contributing doc

[jurica]

Ah I see, but we could still run this on actions as it's possible to run docker containers or am I missing something here?
I could take a look into this, IMHO having a working automated build is worth a lot.

[tjex]

I'm not experienced with running github builds, so if you think it's possible then that would be great :)
I think the issue then making a docker image for mac? I did find this project though:

https://hub.docker.com/r/sickcodes/docker-osx

[jurica]

I filed an issue and outline what I have in mind therefor, then while I'm experimenting we can refine and discuss the goals.
In the past I have setup and maintained quite a lot of CI/CD pipelines so I hope I can also get this done ;).
As for the macOS part, I would just build on plain macOS machines, I don't think the hassle with docker for/on macOS is worth the effort.