
On 18/01/12 00:46, Itamar Heim wrote:
On 01/17/2012 06:35 PM, Livnat Peer wrote: ...
We can't remove cloneTemplate until it is removed from the UI or else we will break functionality. For now we are just going to ensure that it works as it always has until the UI is ready to remove it.
If by ensure you mean you are going to do adjustments for the cloneTemplate code to work then it is not needed.
You can either send a patch to disable/remove this button from the UI or synchronize your patch with a patch from the UI that removes this button.
I don't like the approach of leaving the code because many times we end up with a code that is not used and not maintained.
I don't think a patch which would make existing functionality disabled is the way to go. I expect a lot of times a new functionality will be added, and the old one should be flagged deprecated with a comment as to why (or open a BZ to self to clean it up),
I don't expect that we'll remove functionality a lot of times, this was a gap in the API modeling that enabled us doing that. If i understand correctly then you expect to add the clone disk functionality to the UI before removing the clone template button. Let's assume this requires a rewrite of the command to work with the new DB schema, this would be a throw away code, should it be done? I think not. We have upstream releases which should be stable - preferably with no partial functionality, other than that there is a development going on in upstream and from time to time some of the functionality won't be fully ready, it does not mean the application is broken but a disabled button in the UI or something similar can be a valid state IMO. or collaborate with someone more knowledgeable
on the specific component to make the change in sync, or do the patch yourself.
to make less code deprecated, the old api could wrap the new functionality (call removeDisk in a loop, etc.). it should still be flagged as something to clean up once the api calling it is removed. obviously, collaborating (or doing it thyself) on a sync'd change is easiest, but not always possible.