alain_bkr Why create in advance a S3_2 branch, and not keep development in master until it reaches a alpha status ?
After 3.1 the 3.2 is implicit (in master) until the branch is created, like gcc which is far more critical and complex than Freeciv. https://gcc.gnu.org/develop.html#timeline
Reply To alain_bkr
Why create in advance a S3_2 branch, and not keep development in master until it reaches a alpha status ?
Reply To cazfi
Reply To alain_bkr
Why create in advance a S3_2 branch, and not keep development in master until it reaches a alpha status ?
Yes, branching is where we change the version label to "alpha". That people tend to after branching try (and get) to get in such development that really belongs to master only is another problem. The time our versions live in "stable" (that's what 'S' is supposed to mean) is ridiculous, though it's partly due to compatibility freeze levels.
Somehow related, latest about 3.2 schedule on freeciv-dev: https://www.freelists.org/post/freeciv-dev/Freeciv31-Freeciv32-schedule,1
alain_bkr Ok i understand, and i like one release every 2 years, no matter if it big or small. I just fear 4 maintained branches (2.6 , 3.0, 3.1 and 3.2)
Maybe keep 2.6 , mostly frozen, for old hardware and old libs , and one 3.x release ?
Then 3.2 in 2024 (and abandon/freeze previous 3.x)
Other projects i know like Wesnoth or Lincity-ng do work like this, with only one active version. This is simple to follow and reduces your maintenance burden, and is easy to understand for contributors
/just my 2 cents
Reply To alain_bkr
I just fear 4 maintained branches (2.6 , 3.0, 3.1 and 3.2)
Yeah, number of parallel branches can be a problem. But in practice it has not been as bad as one might expect - most backports are trivial to make (to the extend that 'git cherry-pick' works with no need to do any backporting at all).
As for S2_6, it's sort of officially EOL already, but I've been still pushing some stuff there for people who may build freeciv-2.6 from git. Practically all public servers are still using freeciv-2.6: http://meta.freeciv.org/
Patch going to S3_2 after branching should consider: #46594
Patches to apply to S3_2 and main after branching attached.
This ticket is for collecting things needed for next branching from master, namely that of S3_2.
For reference, ticket about S3_1 branching: https://www.hostedredmine.com/issues/656468
S3_1 was branched in the beginning of February 2021. With the planned every-two-years frequency we then aim to S3_2 branching in early 2023.
Blockers:
- Update custom modpacks: #46366
- Moving actions to actions.ruleset in supplied rulesets, so they will load when 3.1 -> 3.2 compatibility code dropped: #45066 (done)
After branching to the main branch
#47394 - FREECIV_DEV_SAVE_COMPAT_3_3
#47396 - comments-3.3.txt
#47397 - Clean out 3.1-to-3.2 rscompat code
#47398 - Fetch rscompat test rulesets from S3_2
#47399 - 3.3 ruleset capstr and format_version
After branching to new S3_2 branch - potentially repeated on S3_3 branching:
#47380 - Reintroducing ACLOCAL_AMFLAGS to S3_2
#46400 - Clean out 3D stuff from S3_2
Specific to S3_2 branching:
#44375 - Rename of 'master'
#47313 - Replace references to 'master' branch as 'main' branch