New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stable release branch? #792
Comments
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:
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 👍. |
Thanks, @ArashMehraban. I think my question is a bit different. Compatibility of |
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. |
Sorry! I saw that as API, rather than ABI |
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 |
Yeah, as described here with https://git-scm.com/docs/gitworkflows#_managing_branches (ignore |
Thanks, the picture helps. Would it make sense to tag major releases on |
After a new feature release, |
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:👍 Keep
release
branch, potentially tag minor releases likev0.9.1
. Update contributing guidelines to recommend starting bug-fix branches fromrelease
and making pull requests torelease
. We'll merge forward (release
intomain
) routinely as part of maintainer workflow. New feature branches should still start frommain
and the next feature release will bev0.10.0
(presumably) tagged onmain
.👎 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.The text was updated successfully, but these errors were encountered: