What you're doing seems reasonable enough, but it sounds like there are (sound?) process reasons for opposing it. I won't compare the proposed solutions, but perhaps there's a way you could have your cake and eat it too:

If the open source project in question allows it, contribute your back-ported bugfix to their repository. That is, if you're using version 1.5.2 and the current stable version is 1.6.1 by now, contribute a patch to 1.5.2. If it gets adopted, you can fetch the fixed source directly from the repository (perhaps as version 1.5.3) and make everyone happy.

In other words: Patch it for everyone else who's in your situation, too. Of course this is only possible if the project supports (or at least allows) updates to released versions. But that's certainly pretty standard practice these days.

What you want to do seems reasonable enough, but it sounds like there are (sound?) process reasons for opposing it. I won't compare the proposed solutions, but perhaps there's a way you could have your cake and eat it too:

If the open source project in question allows it, contribute your back-ported bugfix to their repository. That is, if you're using version 1.5.2 and the current stable version is 1.6.1, contribute a patch to 1.5.2. If it gets adopted, you can fetch the fixed source directly from the repository (perhaps as version 1.5.3) and make everyone happy.

In other words: Patch it for everyone else who's in your situation, too. Of course this is only possible if the project supports (or at least allows) updates to released versions. But that's certainly pretty standard practice these days.

What you're doing seems reasonable enough, but it sounds like there are (sound?) process reasons for opposing it. I won't compare the proposed solutions, but perhaps there's a way you could have your cake and eat it too:

If the open source project in question allows it, contribute your back-ported bugfix to their repository. That is, if you're using version 1.5.2 and the current stable version is 1.6.1 by now, contribute a patch to 1.5.2. If it gets adopted, you can fetch the fixed source directly from the repository (perhaps as version 1.5.3) and make everyone happy.

Of course this is only possible if the project supports (or at least allows) updates to released versions. But that's certainly pretty standard practice these days.

What you're doing seems reasonable enough, but it sounds like there are (sound?) process reasons for opposing it. I won't compare the proposed solutions, but perhaps there's a way you could have your cake and eat it too:

If the open source project in question allows it, contribute your back-ported bugfix to their repository. That is, if you're using version 1.5.2 and the current stable version is 1.6.1 by now, contribute a patch to 1.5.2. If it gets adopted, you can fetch the fixed source directly from the repository (perhaps as version 1.5.3) and make everyone happy.

In other words: Patch it for everyone else who's in your situation, too. Of course this is only possible if the project supports (or at least allows) updates to released versions. But that's certainly pretty standard practice these days.