This repository has been archived by the owner on Dec 13, 2023. It is now read-only.
Conductor release fixes and impact in older versions #3180
flavioschuindt
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi, folks.
It is very common for users to lock themselves in a specific conductor version for some time until they eventually do a upgrade, i.e., we shouldn't expect customers going to the latest and greatest conductor version easily for a variety of reasons (e.g. internal validations, customers in production running specific conductor versions without capability to do regression, etc.). Having said that, I would like to understand what is the process (if any) to backport important fixes to previous conductor releases. To give examples on this, these are two examples of situations that happened to myself that we can't go to the latest conductor version and at the same time we had issues in PRs being accepted to backport to previous versions: #2674 and #3169.
Of course, from a project maintainability perspective, I completely understand that maintaining multiple releases is challenging, but at the same time I believe we should find a midterm as a solution here. I can think of those common scenarios:
Someone is using conductor 2.X and asks for a fix in that release: For those, we should not include as 2.X is definitely not supported anymore.
Someone is using conductor <= 3.8 (3.7.X) and would like to have a fix in some community dependency (e.g. postgres). If we ask this person to bump to > 3.8 sometiems is not possible (build process completely changed). We should accept the external contribution and generate a patch in that particular version. This patch would generate a new version 3.7.X+1.
This list can go on and on. In general, as a said earlier, we should not accept every single request for patches in the previous versions, but at least we should evaluate if they make sense and are important (e.g. security patches, breaking changes, etc.). Also, they should be trated as priority if the community itself already has a fix, i.e., this shouldn't impact the latest conductor versions development in terms of timeline.
Do you have any opinion on these ideas? If yes, could you please share?
cc: @v1r3n
Beta Was this translation helpful? Give feedback.
All reactions