Hi Roland, Thanks for you very detailed response! I just read the book "The Elements of Style" and will try to make my response short to save readers time.
The Jackrabbit release process is manual, and takes a lot of peoples times. Automating the process also takes time, and it doesn't make sense to do it if you don't release often. But automating doesn't hurt quality, and if we want to release more often, we need to automate some steps. Voting is still possible, but releasing would be a lot easier. Jackrabbit is good quality software: it is well tested, because it is used by many people, and bugs are fixed as they are found. It doesn't have a great test suite, but the code is 'time-tested'. This offsets the lack of unit tests. The problem is: changing Jackrabbit is dangerous. We can't release often and need to maintain a branch. A good test suite would make changes less risk. With an automated release process, we can release more often. We do have the resources to do that. Automated GUI testing is hard, but Jackrabbit is not such an application, so automated testing is possible. What I have automated in my project (H2): - Platform testing (OS, JVM) - Code coverage testing - Performance testing - Running unit tests of software that depends on it - Test if Javadocs are complete - Documentation spell checking - File header checking - Check if all XML is well-formed (including XHTML) - (HTML-) link checking Many of that is currently not done for Jackrabbit. Not all needs to be done. But with all that, changing the code is less risky, and releasing is a lot easier and quicker. You can list tested operating system, databases, file systems, and virtual machines. With a good test suite, users that want to use Jackrabbit on an unsupported platform just need to run the tests. People that want to use different versions of Jackrabbit dependencies can use OSGi or run all tests with his version of the dependency. Short release cycles are possible with all kinds of software. You can do that with operating systems, you can do that with databases (H2). You can do it where the API and behavior is well defined. With Jackrabbit, it is: the JCR API is quite stable. There will be a problem with JCR 2.0, but multiple incompatible API versions can be supported using a preprocessor. For details, see http://h2database.googlecode.com/svn/trunk/h2/src/main/org/h2/jdbc/JdbcConnection.java (look for //#ifdef). Internal Jackrabbit APIs are also quite stable (the PersistenceManager API for example), and new features can be introduced using new interfaces. > a bug is uncovered in an older release. The bug > is reported, maybe even with a patch. And you want to tell > them: "Duh, that release is 6 months old. We've had 12 new > releases since, upgrade to the latest one first and if the > bug is still in there, provide a new fix for that."? Tell them: "Read the release notes between your release and now. If there are breaking changes, disable the relevant system properties / settings. Then try the newest release." Of course you can't help those that don't have good tests, and at the same time rely on undocumented behavior - for those, you would probably need individual bugfix branches, where only the problems they ran into are fixed. > Agile software development requires excellent test coverage. Excellent software requires excellent tests. Functional test coverage, and code coverage. Do you know Crap4J (http://www.crap4j.org)? It's not perfect, but the idea is good. > hard to attract volunteers if you require them to provide full test coverage Stable software is more important than having many volunteers. With unstable software you drive away customers. You also drive away good developers because they always have to clean up the mess of those that don't test. There is a 'sandbox' to try out things. > That does _not_ mean there shouldn't be more test coverage ;-) Yes, but we need to agree we want that. We need to define the target, and the process. Regards, Thomas
