Hi, I know the chances for my proposal are low ;-) Just brainstorming.
> > - Add a lot of tests (functional coverage 100%, code coverage >90%) > Who's going to write all those tests? Mainly Jackrabbit developers, but also users. More automated tests would improve the quality no matter what the release cycle is. But a short release cycle requires more tests. > > - Only check in fully tested features (or mark them as "beta") > Then where do we work together? > We need somewhere where we can try > out, comment on, and co-develop new features (cf. ISM locking, data > store, indexing enhancements, etc.). We could use 'compile time' (constants) or 'run time' switches (system properties) to enable new features (or make them the default) after we consider them stable. Old code is removed when no longer needed. > parts of the release process: > schedule/fix issues I would argue that's an ongoing effort. > test Tests should be run automatically in different environments. > Review/vote on the release Because it's only 2 weeks, people still know what was changed, so this becomes easier. And people would just vote on what settings to enable. > > - Release every 2 weeks > Then what's the difference between a release and an svn checkout? Not much: releases would have no failed tests on target platforms. > we should only make feature release whenever we reach a reasonably > stable state Sure! So would need to make sure the trunk (with default settings) doesn't get unstable ;-) > This will likely > always take longer than 2 weeks for any non-trivial enhancements. Yes, but with compile / run time switches those are not a problem. > What about production environments where you just want bug fixes to a > well tested base release instead of code from the bleeding edge? With enough automated tests the trunk would be more stable than releases are now (at least that's the idea :-) > > - Only one jar file > What about people that just want to depend on our tools that work on > top of the JCR API? I didn't think about that - OK three jar files: API, core, tools Regards, Thomas
