If you are creating an alternative implementation and leaving the old one in place, you are not fixing a problem, you are just creating a new one (and a third one because you have duplication of logic).
Either refactor the old function so that it transparently calls the new logic or delete the old function and replace all the existing usage with usage of the new one. It does not need to happen as a single commit. You can check in the new function, tell everyone to use it, and clean up usage of the old one. If anyone tries to use the old implementation, call them out in a code review.
If removing or replacing the old implementation is not possible, at least mark it as deprecated so that anyone using it gets a warning.
It wish it was that easy. It is a deep rooted problem, because of several other factors.
There’s not just one function that is l dependant on the ringbuffer, but multiple functions in multiple libs and dll’s. Some if these dll’s and libs are used by us, some are used by another department and some are used by both. It has to stay C-code, in order for both departments to be able to use the library. The other department is using pInvoke to call it from a C#-application, or from other dlls. We use it as library in a C+±application, but also for us it might happen indirectly by being called from other libs or dlls.
A proper fix is therefore an immense task, and requires coordinations between multiple teams.
About deprecation, well, we handle warnings as errors, so adding a deprecated-attribute wouldn’t compile. I could add a warning-assert, but that annoys some of the senior developers, and then I have to remove it again.
About code review, many of the seniors often don’t do them and just commit directly…
To sum up, it’s easier to phase it out instead of turning everything upside down.
If you are creating an alternative implementation and leaving the old one in place, you are not fixing a problem, you are just creating a new one (and a third one because you have duplication of logic).
Either refactor the old function so that it transparently calls the new logic or delete the old function and replace all the existing usage with usage of the new one. It does not need to happen as a single commit. You can check in the new function, tell everyone to use it, and clean up usage of the old one. If anyone tries to use the old implementation, call them out in a code review.
If removing or replacing the old implementation is not possible, at least mark it as deprecated so that anyone using it gets a warning.
It wish it was that easy. It is a deep rooted problem, because of several other factors.
There’s not just one function that is l dependant on the ringbuffer, but multiple functions in multiple libs and dll’s. Some if these dll’s and libs are used by us, some are used by another department and some are used by both. It has to stay C-code, in order for both departments to be able to use the library. The other department is using pInvoke to call it from a C#-application, or from other dlls. We use it as library in a C+±application, but also for us it might happen indirectly by being called from other libs or dlls. A proper fix is therefore an immense task, and requires coordinations between multiple teams.
About deprecation, well, we handle warnings as errors, so adding a deprecated-attribute wouldn’t compile. I could add a warning-assert, but that annoys some of the senior developers, and then I have to remove it again.
About code review, many of the seniors often don’t do them and just commit directly…
To sum up, it’s easier to phase it out instead of turning everything upside down.
I’m sure that ring buffer started out as a “temporary solution”.