Discuss branching model

[localheinz]

Currently available branches

As of the moment, we have the following branches:

• main
• 1.12
• 1.9
• 2.x

For unaware contributors, it may be unclear which of these branches are active and which branch they should use as a head branch when proposing changes.

Perhaps it is time to discuss which of these branches we can delete (we can always create a branch based on a tag) and which branches should stay.

Also see #745 for possible version support based on

• development
• active support
• security support
• end of life

Proposed branching model

We only keep major.minor branches around for versions of fakerphp/faker with active and security support.

We do not keep branches for versions of fakerphp/faker that have reached their end of life.

The latest major.minor branch with active support becomes the default branch.

• create 1.23 branch
• rename main branch to 2.0, it is unclear for contributors which version the branch targets
• remove 1.12 branch, do we support this version?
• remove 1.9 branch, do we support this version?
• remove 2.x branch

1.23 branch (active support)

We create a 1.23 branch based on current main.

We use the 1.23 branch for active support of fakerphp/faker:~1.23.0.

2.0 branch (development)

We resolve the divergence between 2.x and main by either merging main into 2.x or the other way around or what have you (as far as I can tell, there has not been much activity in 2.x lately).

We create a 2.0 branch based on the result.

We create a 2.0 branch based on current main.

We use the 2.0 branch for development of fakerphp/faker:2.0.0.

2.1 branch (in the future)

As soon as we tag and release fakerphp/faker:2.0.0, we create a 2.1 branch based on that tag.

We use the 2.1 branch for development of fakerphp/faker:2.1.0.

The 2.1 branch then becomes the new default branch.

Rinse and repeat.

[pimjansen]

I think i mostly agree on strategy. About the release cycle i have no idea if we should make it a strict schedule since there will be a lot of community packages out there as well.

I think the most important is proper guidance on the interfaces

[localheinz]

As an alternative to

2.0 branch (development)

We resolve the divergence between 2.x and main by either merging main into 2.x or the other way around or what have you (as far as I can tell, there has not been much activity in 2.x lately).

We create a 2.0 branch based on the result

we could also consider

2.0 branch (development)

We create a 2.0 branch based on main and re-apply the changes that have been applied to 2.x that we care about.