Release 18 milestone

[AlmasB]

If we're going by the java/javafx release cycle, then the next release should be end of March / beginning of April. This means we have 4-5 weeks to go. If everyone is OK with this, I'd suggest we wrap up outstanding issues and PRs if we can, and re-target to 19 if we can't. All new PRs (unless pure test: or docs:) should now probably target 19.

As soon as javafx 18 is out, we should update and get some users to help thoroughly test SB 18.

[johanvos]

I agree outstanding PR's and issues should now target 19.
I recommend following the OpenJFX approach: create a branch for stabilisation of SB 18 while work on 19 can continue in the main branch.
Testing can be done with JavaFX 18-ea+11 which should be really close to the final 18 which will be released next month.

[Oliver-Loeffler]

I'll see that I can finish #427 next days. Not certain, If I can finish #396 this week but I'll invest some time, unfortunately this one got bigger than expected.

[johanvos]

@AlmasB @Oliver-Loeffler @aalmiray Are you ok with branching sb18 now? If so, I will do that, and someone probably has to change the actions so that 18-builds are created from the sb18 branch.

From that moment on, the 18-branch should only be used to fix showstoppers and critical issues. All new functionality or bug fixes that are not critical (preventing SB to work) should go in main.

[AlmasB]

I think we should:

1. update main to JavaFX 18-ea+11
2. Re-tag early-access for this as 18-ea, so that the release is not overwritten by rolling releases, for testing purposes.
3. branch away to SB18 and leave it until javafx 18 release, then update the branch to javafx 18 and release.
4. continue developing on main as normal

[abhinayagarwal]

This sounds like a good plan. Did we ever get to a point of branching out SB18 ? Now that JavaFX 18 is available we should branch off from a commit which we are most comfortable with.

[AlmasB]

yes, sb18 branch needs updating to the stable javafx 18 and we can release.

[abhinayagarwal]

In addition to JavaFX 18, we need to wait until Java 18 is released.

[aalmiray]

@johanvos @AlmasB the release.yml workflow may be triggered form any branch. The early-access.yml workflow only reacts to changes pushed to master branch.

[AlmasB]

I think we should:

1. update main to JavaFX 18-ea+12
2. Re-tag early-access for this as 18-ea, so that the release is not overwritten by rolling releases, for testing purposes.
3. branch away to SB18 and leave it until javafx 18 release, then update the branch to javafx 18 and release.
4. continue developing on main as normal

All of the above are now done. sb18 branch is there for stabilisation and can be used for release in due time. The PRs can now continue to be accepted to master.

[aalmiray]

You may also configure a different <jreleaser><project><snapshot><pattern> instead of changing the project version. The default pattern is set to *-SNAPSHOT.

[AlmasB]

@abhinayagarwal I believe sb18 is now ready for release. We should probably keep it java 17 for a while, given we just switched to it. Based on the previous releases, perhaps we could keep java 17 until the next LTS release.

[jperedadnr]

In any case, this PR: #544 rolls back the change done to release workflow, so once #542 is merged, we can still release from 'sb18`.

[AlmasB]

The release seems to be stuck on:

          mvn -B -ntp \
            -Drepository.url=https://${{ github.actor }}:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}.git \
            release:prepare
          mvn -pl :parent process-resources

Should secrets.GITHUB_TOKEN be secrets.PAT? Just a guess...

[jperedadnr]

no idea....
@aalmiray can you guess what's going on?

[aalmiray]

I think that release:prepare can be avoided if the version has been set already. SB does not publish JARs to Maven Central.

[jperedadnr]

Ok, then we cancel the workflow. Could you create a PR with Athena required charge? Thx.

[aalmiray]

AFAICT ${{ secrets.GITHUB_TOKEN }} is enough when making commits to the same repository where the GH workflow is run, which is the case for the release workflow.

[aalmiray]

FWIW @jperedadnr your commit message does not follow the Conventional Commits spec

[jperedadnr]

Which one? Can you elaborate?

[aalmiray]

commit 981b2650fca45911b04837b435ca40fcac78a9de (HEAD -> release-update, origin/master, origin/HEAD, master)
Author: José Pereda <pereda@eii.uva.es>
Date:   Tue Mar 29 18:25:54 2022 +0200

    Use Java/JavaFX version 18 (#542)
    
    Co-authored-by: jose.pereda <jose.pereda@gluonhq.com>

See https://github.com/gluonhq/scenebuilder/blob/master/CONTRIBUTING.md#pull-request-standards

[jperedadnr]

I added build to the PR title only, not to the commit message, I see.

[aalmiray]

PR is ready for review #545

[jperedadnr]

Once we merge this, we should run release workflow from master, right? There is no point in having sb18 branch anymore then...

[jperedadnr]

@aalmiray @AlmasB I believe master branch is ready for starting the release workflow from the master branch (and not from sb18). Any comment? Else I'll start it.

[aalmiray]

I'd say, go for it!

[jperedadnr]

hmm
https://github.com/gluonhq/scenebuilder/runs/5754075429?check_suite_focus=true#step:6:75

remote: error: GH006: Protected branch update failed for refs/heads/master.        
remote: error: At least 1 approving review is required by reviewers with write access. 

[jperedadnr]

Let's see: #547

[jperedadnr]

Feel free to approve so we can test (at this point another failed workflow doesn't make a difference ;) )

[AlmasB]

Does GH allow the PR author approving their own PRs? If so, perhaps, we should do that for now -- for the purposes of an expedient solution.

[jperedadnr]

Usually you can approve yourself, unless there are restrictions added to the repository (like the need of having at least one approval)

[jperedadnr]

Merged, let's see how it goes now...

[jperedadnr]

hmm
https://github.com/gluonhq/scenebuilder/runs/5760399516?check_suite_focus=true#step:7:31
@aalmiray , help!

Error: s3.app.region must not be blank. Configure a value using the Maven DSL, or define a JRELEASER_S3_APP_REGION environment variable, or define a key/value pair in /home/runner/.jreleaser/config.properties with key = JRELEASER_S3_APP_REGION
Error:  s3.app.bucket must not be blank. Configure a value using the Maven DSL, or define a JRELEASER_S3_APP_BUCKET environment variable, or define a key/value pair in /home/runner/.jreleaser/config.properties with key = JRELEASER_S3_APP_BUCKET

Workflow has JRELEASER_S3_GLUON_*, not JRELEASER_S3_APP_*??

[aalmiray]

According to the log the s3 section has the following configuration

upload:
    enabled: true
    s3:
        gluon:
            enabled: true
            active: release
            connectTimeout: 20
            readTimeout: 60
            artifacts: true
            files: true
            signatures: false
            checksums: false
            region: us-east-1
            bucket: s3://download.gluonhq.com
            accessKeyId: ************
            secretKey: ************
            sessionToken: **unset**
            path: scenebuilder/{{artifactFile}}

The configured bucket name (as coming from the secrets) includes the s3:// protocol and a custom domain. This won't work as is.
I'm assuming there's an *.amazonaws.com URL that can be used to upload SB artifacts, something similar to https://{{bucket}}.s3.{{region}}.amazonaws.com. If this is the case then we just have to update the value for bucket.

[aalmiray]

OTOH if a custom S3 endpoint (such as download.gluonhq.com) should be used then please configure a value for the <endpoint> property but be sure to also configure a value for <downloadUrl> and <bucket> properties. See https://jreleaser.org/guide/latest/configuration/upload/s3.html for reference (click on the Maven tab).

[jperedadnr]

We have renamed the bucket to download.gluonhq.com, trying again now.

[jperedadnr]

Looks like we have a winner!
GitHub releases and S3 have the artifacts!

[jperedadnr]

FYI: I've also built Scene Builder on my M1, and pushed the binary to the release assets. In case anyone can test it.

(I already have a self hosted runner to build on M1, but needs some wiring to the release process..., we can do that later)

[AlmasB]

Right, just to "close" this discussion, 18 is now out (many thanks @aalmiray @jperedadnr ). I've fixed the legacy changelog commits, so they work with the new format, but the next version shouldn't have these issues.