Every so often either because macOS breaks it or because I simply prefer to be on the newest behavior I want to upgrade my projects to the latest version of OPENRNDR, but I‘m not sure exactly of the best way to do it is. What usually ensues is that I faff around with the gradle build file, but I also think I’ve created entire new projects from the template and the copied the old files into that.
So what‘s the cleanest, easiest and best way to upgrade exisrting OPENRNDR projects to the newest version?
It depends: are you using the OPENRNDR + ORX releases (User) or building them locally (Dev)?.
If you use official releases (simpler) what I do is to clone the openrndr-template once in a while and compare it with my other local copies. I use meld but there are other similar tools like Beyond Compare to compare two folders showing what’s different and allowing to bring changes line by line. I focus mostly into the gradle files. Normally the changes are just a few lines, but there has been larger rewrites to clean up things and make them easier to maintain.
By doing this you may get newer openrndr + orx releases when they are referenced in these lines.
If you prefer to be on the edge you can use local SNAPSHOT versions. This way you don’t have to wait for new releases to happen. This approach lets you make changes to the framework, try fix bugs and maybe contribute. Even if you don’t want to touch the code, it lets you try the latest features maybe weeks or months before they are released. In this case you would:
- Maintain your local openrndr-template the same way I mentioned above, but have snapshot set to true. What that does is to skip the released packages available in maven and use packages built locally.
- Clone openrndr and orx once into your computer so you can build them locally.
- When you want to update them: pull changes for both.
- To build them run
./gradlew publishToMavenLocal -P"release.version=0.5.1-SNAPSHOT" first for openrndr, then for orx. It can take a minute or two the first time. If you make changes to the code building for a second time takes a few seconds.
Was your question about the first or the second case?
My question was about the first case. Sounds like what you suggest is similar to what I do already, just more efficient!