Stable release branch?

[jedbrown]

Some of you may have noticed that there is a release branch in the repository now. I'm curious if we should start distinguishing main development from ABI-compatible bug fixes, perhaps as a warm-up for practicing more strict SemVer when we reach 1.0. It's another thing to pay attention to when fixing bugs and creating/reviewing PRs, but not bad once you get the hang of it. I think we should eventually do this, but I'm not sure it's worth doing yet. A related discussion is what should be present to release 1.0. So a poll, and solicitation of comments:

:+1: Keep release branch, potentially tag minor releases like v0.9.1. Update contributing guidelines to recommend starting bug-fix branches from release and making pull requests to release. We'll merge forward (release into main) routinely as part of maintainer workflow. New feature branches should still start from main and the next feature release will be v0.10.0 (presumably) tagged on main.

:-1: Let's wait (for any number of reasons). It's added complexity and not enough value to justify. Let's keep main moving for now and perhaps revisit after future feature releases.

[ArashMehraban]

I periodically read the source code to see if any significant changes have occurred that might be problematic in case older versions of PETSc is used for example (3.13, 3.14). Of course, I mostly check out the solids code for testing. In addition, I have found numerous cases that the provisions we have put in that code (solid) do not resolve the issues. That is on top of the fact that I feel like the solids code, and perhaps fluids code should be restructured to have a more flexible design for the add-ons I have in mind. To provide a few examples from the solids code:

1. The elasticity.c (or main in general) code is too cluttered up and many things from there must be moved somewhere else. For example, the preconditioning is almost in the middle of that code in is entirety.
2. ProcessUserOptions computes things that are related to the natural BC. That function has no business computing things!
3. I’d like to have more flexibility with BC and that needs to become its own module, i,e. its dependencies will matter
4. I want an api in ‘main’ to control PETSc solvers, etc.
5. I want multi-materials

So, I personally, prefer to be able to work with a stable ‘release’ and get something working and call that example the one that works with version x.y.z.. So thumbs up 👍.

[jedbrown]

Thanks, @ArashMehraban. I think my question is a bit different. Compatibility of examples/solids/ with PETSc versions, and really anything in examples is an entirely separate matter. Feature requests for the examples can go in a different issue (or submit a draft pull request and we can work with you). What I'm asking here is whether libceed.so should get updates that promise to be ABI-compatible (don't need to recompile user code), and specifically whether it's worth the development workflow cost to do that at this time.

[jeremylt]

Personally, I'm of the mind that we should try the new workflow now before we get to 1.0. Currently, a lot of bug fixes get swept up in feature change PRs and squashed, so this will take some (mild) effort to improve our discipline in handling bug fixes separately from feature development.

[ArashMehraban]

Sorry! I saw that as API, rather than ABI ☺️

[nbeams]

Overall, I like the idea of having two separate branches and starting to separate pure bug fixes from new features, but I'm not quite sure I understand the exact workflow being proposed. Is the intention to tag minor releases on release, but major releases on main?

[jedbrown]

Yeah, as described here with maint and master replaced by release and main. Bug fixes are created from release and merged to release. Feature branches are created from main and merged to main. The release branch is merged to main regularly by a maintainer (so main is always a superset of release, and thus gets bug fixes without duplication/cherry-picking).

https://git-scm.com/docs/gitworkflows#_managing_branches (ignore next as described here)

[nbeams]

Thanks, the picture helps. Would it make sense to tag major releases on release as well? It seems to me that if a user checks out a branch named release, it should always be possible to update to the latest release from there.

[jedbrown]

After a new feature release, release fast-forwards to the new release. One can leave an old release-1.x branch if someone (like RedHat) needs long-term support for older releases, though it comes at a development cost to identify the oldest release on which a bug fix is relevant.