Propose new Trilinos release model
Created by: mhoemmen
@trilinos/framework @maherou @jwillenbring @bartlettroscoe
PR https://github.com/trilinos/Trilinos/pull/4259 led to a discussion about Trilinos versions, deprecation, and the Trilinos release model. I wanted to summarize that here, and propose the following:
- Drop the official policy (which we haven't followed for years anyway)
- Embrace the current de facto policy (which I'll summarize below)
- Help users write code that works with multiple Trilinos package "versions"
Official policy
Here is Trilinos' official policy:
- Minor release every quarter
- Major release every year
- Backwards compatibility breaks only at major releases
- If you want to break an interface, you must deprecate it the last minor release before a major release
When was the last time we did any of this? At least three years? We made a 12.14 release tag, but I wouldn't call that a "release" in any sense. @crtrott and I spent a ridiculous effort in Tpetra not to break backwards compatibility when we converted it to use Kokkos 2.0; the utter lack of interest in the release policy post 12.0 makes me feel like that was a waste of time.
De facto policy
@ikalash, @rrdrake, @theguruat12, @micahahoward, @rppawlo, or @trilinos/framework may wish to chime in, but I would summarize the de facto "Trilinos versioning" policy for many internal applications as follows:
- App either forks Trilinos, or picks a Trilinos "master" branch commit.
- App defines its own acceptance testing for Trilinos.
- When an app wants to update its Trilinos, it uses acceptance tests to decide when to merge / pull. Many apps facilitate this by testing the app nightly against current master Trilinos.
- Apps put pressure on Trilinos as needed to support their goals. Individual Trilinos developers use guidance from their managers to prioritize.
This implies that apps define their own "Trilinos versions." Apps actually get work done with this model. That, along with open access to Trilinos' repo on GitHub, likely explains the lack of enthusiasm for official Trilinos releases. I've gotten about as many complains about deprecation warnings ("hey, we can't build warning-free") as I've gotten about actual interface changes, so it's likely less effort just to break the build than it is to do an official deprecation (how long? who knows, since no official releases!).
Help users write code that works with multiple Trilinos "versions"
What's missing from this model is a way for an app to work correctly with multiple Trilinos package versions at once. For example:
void my_app_function () {
#if PACKAGE_FOO_VERSION < SOME_MINIMUM
old_foo_function ();
#else
new_foo_function ();
#endif
}
A few packages have added this feature themselves. For example, Kokkos has a CMake option and macro to help manage deprecation. Tpetra just recently added this.
Proposal
I propose the following:
- Support the current de facto policy (see above).
- Packages that have enough users to care, should define their own release cycle and policies.
- Such packages should define macros to enable or disable deprecated code.
- Such packages should define macros to test the version number in code. Version number can be whatever the package wants, as long as users can test when it increases.
The only packages that would need to opt in, are packages with external users who care about this policy, and whose interfaces change. Kokkos does all of these but (4), and (4) isn't hard (Kokkos has an outstanding issue to implement it).
Summary
- Embrace what we're doing now anyway.
- Packages who care can add their own version macros.
What do y'all think?