René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Nightly builds","articleBody":"\nPremise: We would like to distribute builds of Processing with upcoming features for people to try out without those features necessarily being included in the latest builds of Processing.\n\nOne thing that was already suggested before is we could manage these features as a build step, so that they can be included into the main branch without being necessarily activated\n\nMy suggestion for feature control would be: we add a `gradle.properties` to the repo and add subsequently it to the `.gitignore`, this will provide a template for the file that then can be freely modified by anyone building the project from scratch. We can also create `gradle.nightly.properties` or something similarly named, that will enable features on the nightly builds but not in the main build. In this way you could activate the feature on a build system level by checking the property:\n\n```build.gradle.kts\nif(property(\"includeExamples\") == \"true\"){  \n    create(\"examples\"){  \n        java{  \n            srcDirs(\"examples\")  \n        }  \n    }\n}\n```\n\nFor feature control in the code we could grab all the Gradle properties defined starting with `processing.feature` and pass them through to the rest of the code. This would mean we could activate them with the following:\n\n```java\nstatic private String ExampleFeatureActive = Boolean.parseBoolean(System.getProperty(\"processing.feature.example\", \"false\"));\n```\n\nThe nice thing is that the gradle.properties are also easily modifiable within the Github Actions:\n\n```yaml\nname: Build with Gradle  \n  run: ./gradlew publish  \n  env:  \n    MAVEN_CENTRAL_USERNAME: ${{ secrets.MAVEN_CENTRAL_USERNAME }}  \n    MAVEN_CENTRAL_PASSWORD: ${{ secrets.MAVEN_CENTRAL_PASSWORD }}  \n  \n    ORG_GRADLE_PROJECT_mavenCentralUsername: ${{ secrets.MAVEN_CENTRAL_USERNAME }}  \n    ORG_GRADLE_PROJECT_mavenCentralPassword: ${{ secrets.MAVEN_CENTRAL_PASSWORD }}  \n  \n    ORG_GRADLE_PROJECT_signingInMemoryKey: ${{ secrets.SIGNING_IN_MEMORY_KEY }}  \n    ORG_GRADLE_PROJECT_signingInMemoryKeyPassword: ${{ secrets.SIGNING_IN_MEMORY_KEY_PASSWORD }}  \n  \n    ORG_GRADLE_PROJECT_version: ${{ needs.version.outputs.version }}  \n    ORG_GRADLE_PROJECT_group: ${{ vars.GRADLE_GROUP }}\n```\n\nOne challenge that I see with nightly builds is keeping track of revision numbers and versioning. \nRight now any time a new release of Processing is created, we manually set the revision number and version, the Github actions responsible for those expect that in the format `processing-$revision-$version` and this is parsed to set those variables into the gradle build system. \n\nWe could either start creating versions with a tag to it, e.g. `processing-1501-4.10.1-nightly` and just increase the build tag every time. But we would run out of revision tags rather soon and I suspect it might be hardcoded into multiple placed to be 4 digits.\n\nFinally we would need to update the website to ignore build released with any arbitrary tags so that only major versions would be shown within the website. \n\nLets discuss! \n\n@catilac @SableRaf @tychedelia \n","author":{"url":"https://github.com/Stefterv","@type":"Person","name":"Stefterv"},"datePublished":"2025-11-19T10:00:41.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/1332/processing4/issues/1332"}