I work specifically on maintaining release versions of a commercial software package. Unfortunately this problem afflicts me too, because are process is not as I would have it in my dreams.
I get a defect piled onto me. I dig around in the symptoms and hopefully figure out what's wrong. I add tests to show whether it works or not, and then show my proposed changes fix the problem.
Then I commit those changes and mark it fixed.
It may not ship for 2 months.
This is a point of frustration for me, but we can't release the same day -- we should do *some* general testing before we issue a publically available release. And the general testers have to work on future work as well as production point releases, as well as special one-offs. It's just not easy all around. But from my view as a developer, if I've proved I've fixed it, it's fixed. I'd much *rather* have a customer get at test build that both confirms the fix satisfies the real need and gives them a stopgap solution. But I don't get to make the call, and the customer is often not willing to run such 'experimental' changes, even if they are the changes they themselves need.
It's just a kind of icky thing about software. Tighter cycles would help, up to a point.
Posted Feb 9, 2012 14:29 UTC (Thu) by renox (subscriber, #23785)
[Link]
[Then I commit those changes and mark it fixed.
It may not ship for 2 months.]
Lucky you, I work in a field where there may be *years* between a fix and a new SW version containing release.
And users won't upgrade, so it makes debugging very frustrating: OK, I've spent one week of analysis to find out that the issue was corrected two years ago, please upgrade?