Ortools release management

[gregy4]

Hello,
I'm thinking whether it is possible to improve release management of ortools stable versions. In last versions, especially for cp-sat solver are shortly after release of stable version found and often quickly fixed important issues for me on main branch but not in stable branch.

Is it possible for example one month before a release to annouce public testing of or-tools to find errors that influence usability of future stable version?
Or should be main branch considered as stable branch? What version is used internally in google?
In case someone even outside google should maintain stable version (it seems that ortools are used heavily also outside google) with added fixes from main branch it should be nice to mark important fixes for stable version (label should be enough) and don't mix various changes in one commit like 5e62dde this week when it seems that fix of time limit is mixed with changes in routing cuts.

To what extent do users prefer working with the stable version of OR-Tools?

Thanks,
Jan

[lperron]

in the 1-2 months before the release, the main branch is unstable as we are consolidating all runners on all platforms, updating all dependencies (which usually does a lot of damage). Furthermore, most users are on python, java, .NET and we need to build the artefacts for the code to be tested.

The current plan is to do a 9.13 soon without a release candidate (next week, or the week after, no promise). Then quickly do a 10.0 rc1 which will break compatibility with the routing library. I expect that 10.0 real release is months away, and multiple release candidates away.

[Mizux]

My 2 cents:

1. main is our dev branch mostly in sync with google3.
   note: which mean all internal stuff will first land on main.
   note2: google3 beeing only: blaze based build (bazel internal version), Linux focus, clang only and C++20 enable -> often the cmake, gcc, windows and macos build is borken and need some fix to be backported...
   ref: https://opensource.google/documentation/reference/glossary#google3
2. stable branch is always pointing to the last release tag (e.g. v9.12) and is our default branch (the one you get when git clone git@github.com:google/or-tools.git)
3. all v9.* are currently built from v99bugfix branch so if you want a preview/test the next incoming 9.13 don't hesitate to test this branch !
4. All stuff we would like to add before the release is there https://github.com/google/or-tools/milestones
   note: sometime few are posponed last minute if too long/impossible to fix and want to release ASAP
   note2: we also try to keep in sync main and v99bugfix backporting everything except the constraint_solver's routing migration to
   routing/ stuff.

[lperron]

So v99bugfix branch is pretty close to release. Please hammer away at it :-)