Future release workflow

[AlmasB]

Right, now that we are generally familiar with the dev / release workflow, it would be good to start discussions on rationalising the approaches. So, should we:

• delete sb17 and sb18 branches
• create a new generic release branch for all releases to avoid creating a new branch each time

When it's time to freeze (e.g. java and javafx 19 are both out), we update versions, then dump master to release. We can continue working on master, but release is frozen and can be user tested with early releases and such. When we are happy, we just trigger the release workflow from the release branch.

@abhinayagarwal @jperedadnr sound reasonable?

[jperedadnr]

Sounds good, but we'll need some fine tuning and make sure release.yml can run from other branches different than master)

[Oliver-Loeffler]

Hello all!
With some luck we can get some issues solved and possibly the one or other PR merged within next 2 months.
What about publishing then Scene Builder 19.1.0 as soon as some more bug fixes / functionality has been added? Even maintenance / refactorings could be published.

What do you think about that?

[johanvos]

Hi,
In general, I am in favour of the idea of merging PR's shortly after a release, so that they can be tested for some time before the next release. We can always do interim releases, either 19.1.0 or 19.0.1, or do ea-releases (e.g. 20-ea+1).
In any case, I'm absolutely +1 on moving forward with some PR's now, so great suggestion!