Discussions

In "The CVS cop-out and the stranded user," Nathan Willis makes the point that issues fixed in CVS aren't fixed at all: until they're released as a binary, the issue exists, plain and simple.

One of my biggest pet peeves with open source software is what I call the CVS cop-out. It works like this: I criticize (accurately) some shortcoming of an open source application either in an article or in conversation, and someone responds with, "That's not true! That feature was fixed in CVS four weeks ago!"
Or words to that effect. As if that makes the bug that I want to talk about a non-issue. As if it is inaccurate to discuss a bug in the shipping version of an app just because there's a fix in beta, alpha, CVS, or patched on the developer's mailing list. It is a developer-centric perspective, unhelpful to the user.
You really have to have blinders on to think that a patch in the revision control system marks the end of the issue. The majority of Linux and open source users get their software in pre-compiled binaries, and not from CVS, SVN, or any of the alternatives.
Furthermore, although I'm not sure how you could accurately measure this, I am willing to bet that the majority of Linux users consistently run the version of each app that is supplied by their distro. Even in a rapid-release-cycle distro, in many cases the distro's version is one or more point-releases behind the latest revision of the app (due to the testing and integration required). To the mass market, "four weeks ago in CVS" might as well be a year in the future.

While his canonical example is an audio player, the problem certainly occurs in Java programming, too. JSRs even exist (JSR-277, the Java Module System; JSR-294, Improved Modularity Support; and JSR-291, Dynamic Component Support, the OSGi support JSR) to try to help offset some of the dependency hell projects suffer.
How would you address the problem in Java applications? is a constant release schedule enough, or will the JSRs in process be enough, when they finally get finished and implemented?

It is the same in proprietary software. Once a fix is checked in, it becomes somebody else's problem to deliver to the customer. Most developers take no interest or ownership of their code beyond getting it into source control, and many corporate organizations active discourage them from doing so. They are supposed to keep their heads down in the code. When a developer starts caring about how many of his fixes have actually reached the end user, then he has probably already been promoted and is no longer just a developer anymore.

In closed source projects, when you buy a product release you expect it to get supported for a while, then, some time later, a new version comes out for which you have to pay for. What you get when you buy a release is not just that point release, but the maintenance of it.
When you get an OSS product -for free- you get exactly the support you pay for. Zero. There is little economic value in a project maintaining a branch of the previous shipping version and trying to keep it in sync with a CVS/SVN head with new features. Its only possible if you have not just a large user community, but a large developer community including people who care about keeping the old release patched.
Whenever we get a bugrep in the project I work on, "Have you tried in CVS" is the first response people get because there are lots of changes there, and if the problem has gone away then it is effectively fixed. Furthermore, by making the user download the source and build it, you are setting them up so they are in a state to find the problem and patch it, if it is not yet fixed. So yes, I do like to encourage end user access of the repository, not just to cop out on support for released versions, but to get end user participation. Every user with a problem is a developer with a patch, a use case, or a documentation enhancement.
The big problems are delays in product releases, and then further delays in getting this downstream. Linux has it bad because the distros try and bundle lots of stuff and integrate it all. We (speaking for the ant team here) try and coordinate a bit better with the IDE people, but it does add delays.
The worst comes when someone bundles their own modified release in with their own product; WebLogic springs to mind here. Who wants to field bugreps related to a version of your product that someone else built and shipped and which appears to have modified starter scripts and other changes? Nobody. The first response there is not "have you tried CVS", its "have you tried a real release".
-steve

As the author notes, source code is not relevant for end users. The development process is about getting stuff into svn (no self respecting java programmer uses cvs at this point unless they consider version history and refactoring irrelevant). Release management is about converting stuff in svn into a usable end product.
The release process for most large project is such that it takes at best weeks (and usually longer) to get any given fix in an actual release. The process generally involves large amounts of testing. Then the next issue is getting the release integrated in relevant other projects (e.g. linux distributions *cough* Debian *cough*). Unfortunately release management generally stops when the compile binary is published. The rolling out of the fix is someone else's responsibility.
In Java the problem is that any reasonably sized software package depends on dozens of third party software components. If for example a security bug is found in apache's popular commons-logging component it would take forever to get the fix rolled out in dependening projects. There would likely remain mission critical server applications with the buggy version included for years after the fix lands in svn. Apache fixing the bug, releasing a fixed binary and notifying the development community of the fix does not actually address the issue that there are millions of deployed copies that need to be replaced with the new version.

I totally agree. The fact that there's "beta, alpha" has nothing to do with the version repository, nor the fact that the project is open source. In fact the benefit of open source is that you may have access to the source before the next release is avaialble if you want to see the fix.
Every product will need to go through QA processes, integration testing, etc, etc. This generally means that on top of the time-gap between a bug being reported and being addressed, there is also a gap between it being fixed and being released.
This all makes perfect sense and I can't see the point of the article. Perhaps in some open source projects where testing resources are limited the cycle is longer than other projects, but nonetheless there is always a cycle (or at least should be).

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.