Branches `flint-3.1` and `main` have diverged about flint

[edgarcosta]

In particular, this fails on v3.1.3 (but works on main)

 ./configure --host core2-linux-gnu 
checking build system type... x86_64-apple-darwin21.6.0
checking host system type... Invalid configuration `core2-linux-gnu': machine `core2-unknown' not recognized
configure: error: /bin/sh ./config/config.sub core2-linux-gnu failed

[edgarcosta]

and in v3.1.3 we can do
./configure --enable-arch=core2

[albinahlback]

Not sure why the branches have diverged, but why would that be bad?

[albinahlback]

In particular, this fails on v3.1.3 (but works on main)

 ./configure --host core2-linux-gnu 
checking build system type... x86_64-apple-darwin21.6.0
checking host system type... Invalid configuration `core2-linux-gnu': machine `core2-unknown' not recognized
configure: error: /bin/sh ./config/config.sub core2-linux-gnu failed

Yes, because I changed the build system to be more GMP-like. I think it is better to push everything into --host instead of some non-standard option --enable-arch.

[edgarcosta]

Not sure why the branches have diverged, but why would that be bad?

It leads to several inconsistencies:

• different options for ./configure
• different workflows

I would expect the release versions to be tagged on the main branch, not on some other branch.
But perhaps, what I am struggling with is what is the purpose of the branch flint-3.1?

[albinahlback]

I would expect the release versions to be tagged on the main branch, not on some other branch. But perhaps, what I am struggling with is what is the purpose of the branch flint-3.1?

Bill made new branches for each minor version, which is why we still do it today. I am all for removing those branches.

It leads to several inconsistencies:

• different options for ./configure

This is because I have changed the options in configure.ac. If you go back two years ago, the options are very much different. I have tried my best to streamline them (if you remember, it used to be a single shell-script that did not have a lot of checks or logging features), but I would still class it is a working project which is why we have these inconsistencies between the releases.

[fredrik-johansson]

I would expect the release versions to be tagged on the main branch, not on some other branch. But perhaps, what I am struggling with is what is the purpose of the branch flint-3.1?

We have spun off such branches so that we can do the final release polish (and post-release bug patching) without interference from unstable development on the main branch. I'd be happier with having a strictly linear history where releases are just tags on the main branch (this is what I did with Arb), but this is difficult as long as patch releases are wanted/needed.

[edgarcosta]

I think we are all aligned, then.
I agree that a linear history can be hard.
Do you think it is possible or desirable to aim at updating the release branch flint-3.x when patch releases are wanted/needed through cherry-pick?

At the end of the day, I am just aiming for some consistency, as for me it was quite confusing why we were still running old workflows and supporting different options for ./configure in the releases.

[albinahlback]

I think we are all aligned, then. I agree that a linear history can be hard. Do you think it is possible or desirable to aim at updating the release branch flint-3.x when patch releases are wanted/needed through cherry-pick?

I cannot recall doing anything other than cherry-picking. Could the divergence be explained by conflicts or something when cherry-picking?

At the end of the day, I am just aiming for some consistency, as for me it was quite confusing why we were still running old workflows and supporting different options for ./configure in the releases.

What do you mean by old workflows?

[edgarcosta]

git diff --stat upstream/flint-3.1..upstream/main

 .github/codecov.yml                                                   |    4 +
 .github/workflows/CI.yml                                              |  175 ++++++++++--
 .github/workflows/push_CI.yml                                         |   65 +----
 .github/workflows/release.yml                                         |  124 +++++++--
 .gitignore                                                            |   10 +-
 AUTHORS                                                               |    4 +-
 CMake/FindCBLAS.cmake                                                 |   33 ++-
 CMake/Findgmp.cmake                                                   |   66 +++++
 CMake/Findmpfr.cmake                                                  |   57 ++++
 CMake/cmake_config.h.in                                               |    5 +-
 CMakeLists.txt                                                        |  166 +++++++++---
 ...

https://gist.github.com/edgarcosta/1f6f7b9638a39e9b33f0e03dd5cf75a1

[albinahlback]

We are in 3.2.0-dev though

[edgarcosta]

I do not follow. Can you elaborate a bit more? Are you referring to the VERSION file?

[albinahlback]

I believe next version we will release is 3.2.0, so comparing against 3.1.X doesn't really make sense I believe.

[edgarcosta]

I finally understood where I misunderstood the whole thing 🙃
I am used to the old schedule release where "minor versions" like 2.x were released at the pace of major versions, and thus I still think of "3.1.x" as minor versions, instead of just patches on top of 3.1, and thus why it is has a minimal number of commits on top of the previous version.