We’re excited to announce the release candidate for Processing 4.3.1! This update brings tooling improvements and a friendlier experience for contributors.
This is a preview version, so we’re inviting you to test it out, report any issues, and provide feedback to help us polish it for a full release. Try your existing sketches, run the included examples, and if you spot any issues, let us know!
This update is focused specifically on tooling improvements and a smoother experience for contributors. It doesn’t include fixes for outstanding bugs already present in 4.3. However, the improved build system and CI/CD should make it easier to address issues in the future.
For JavaFX-related issues, please see the Processing JavaFX repository on GitHub. We also welcome any contributions aimed at tackling these issues!
Thank you for your understanding and continued support
A new repository? Interesting…
Hopefully new PRs will be attended to from now onwards?
And good to see the move to Gradle, but there’s not yet a v4+ artefact at Maven Central: org.processing:core.
I think processing4-javafx should now also be Gradle-ised. For instance my mavenised processing-core-4 incorporates this alongside the core (and alongside the Processing net, io, pdf libraries). Either the core artefact needs to incorporate these directly, or each needs its own artefact.
All I want is all the seven modules instead of two or three as it currently stands. It’s such an easy thing to do and I have repeatedly asked for them to be added. I also submitted a pull request to add them.
Thanks for the feedback! We published Processing Core 4.3.1 on Maven yesterday, but there’s a delay with it appearing on Maven Central. We’ve reached out to Sonatype support and hope to resolve it soon.
Regarding contributions, we’re committed to improving how we welcome and integrate them. It will take a bit of time to organize, and we’ll definitely need community help reviewing PRs, but we’re focused on making the process more open and welcoming!
The new CI/CD and local setup should help with that. Feel free to give them a try! Gradle migration is next. The roadmap will be published soon and should hopefully clarify priorities
CI/CD stands for “Continuous Integration” and “Continuous Deployment.” In the context of Processing, this means that testing, building, and releasing new versions of the software is now fully automated.
Each time we create a new release on the Processing repository, a script builds the software for all supported platforms, directly from the source code. It then signs the code*, and adds the resulting files to the release. Note: For macOS, the CI/CD also completes a process called “notarization,” in which Apple scans your application to make sure it is safe to run.
CI/CD automates a complex process that used to be done manually, reducing chances for errors, and making the release process faster. It will eventually allow all contributors to easily create test builds and maintainers to more quickly review pull requests.