[palata]

Oh yeah, that's for sure.

But my experience has been that most managers are not competent in that regard. If you have a good manager that understands that, then that's great. But it's rare. Most of the time, it works better to bullshit them with the legal consequences of not allowing you to upstream your changes.

Again, that's my experience.

[em-bee]

i'd tell them, i we don't get the changes upstream then we can't ever upgrade to their new version.

[palata]

Which is bullshitting them, right? You can upgrade and re-patch.

[em-bee]

no more than claiming that we are legally required to upstream the patch.

the argument is though that repatching is work, and especially it's the kind of work you do not want to be stuck with while you upgrade, because if you forget to do it ahead of time, which is likely to happen, you end up with a potentially large downtime or an unexpected delay in the upgrade process.

in other words: the actual truth is: we can't upgrade unless we reapplied the patch to the new version. basically, it is about making the re-patch process appear as dramatic and disruptive as possible.

the leaders can't deny the possibility, because the code that is patched could change dramatically, to the point that you have to redo all the work from scratch.

i am actually stuck in such a situation with one of my projects. i need to merge two branches that were created some time ago causing a divergence that would have been easy to deal with, had i properly merged the branches at the time. now the merge will take as much effort as the original development.

as developers we all know this of course. the challenge is to explain this to the leadership in ways that they can understand.