It is fine for me. Just curious: why backporting instead of using git
merge? I mean real merges, not rebases as we do on github. Maybe it
would have to be done on the command-line (I'm not sure that github has
the necessary user-interface). The workflow would be:
* Master branch represents 4.0.0-SNAPSHOT.
* Preview branch represents 4.1.0-SNAPSHOT.
* Execute an initial `merge master --strategy=ours` on the preview
branch. It will not make any change in the preview branch, but will
record that the next merges from `master` to `preview` will consider
only the commits after this point.
* Commits on master.
* When there are a bunch of commits that we want to port to the
preview branch (4.1.0-SNAPSHOT), use `git merge` from master to preview.
* If there are a series of commits that we don't want to port to the
preview branch, first merge the commits that we want, then
execute `merge master --strategy=ours` again for skipping the
unwanted commits.
I'm maintaining that way 3 branches in the Apache SIS project for a
similar reason.
Martin
Le 07/10/2025 à 12:15, Guillaume Nodet a écrit :
Hi all,
I’d like to suggest we switch the master branch to 4.0.0-SNAPSHOT and
enable new features as “preview” options, guarded behind feature flags.
Maintaining the gap between master and 4.0.x has become increasingly
difficult, especially around tracking which changes have or haven’t been
backported. By making master represent 4.0.0-SNAPSHOT, we can include all
upcoming features with their default disabled, allowing contributors and
advanced users to experiment without impacting stability or production uses.
(...snip...)
