Hi, On Jan 14, 2008 10:24 AM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > I know this is radical, anyway:
Thanks, good to have also radically different viewpoints! I'm going to shoot it down below, but you certainly have some good points that we probably should adopt in one way or another. > - Add a lot of tests (functional coverage 100%, code coverage >90%) Who's going to write all those 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.). What better place to do that than trunk? (One could go on a tangent about distributed version control here, but let's pass it for now...) > - Reduce release overhead (automate everything) There are four parts to the process of making a releases: 1) Prepare for the release (schedule/fix issues, test, branch/tag when ready etc.) 2) Package/build the release 3) Review/vote on the release 4) Publish the release We can further automate parts 2 and 4, but they are already now reasonably straightforward and by far the most overhead to making a release comes from parts 1 and 3 that can't really be automated. > - Release every 2 weeks Then what's the difference between a release and an svn checkout? IMHO we should only make feature release whenever we reach a reasonably stable state for the new features and improvements. This will likely always take longer than 2 weeks for any non-trivial enhancements. We can certainly do patch releases more often. > - No branches What about production environments where you just want bug fixes to a well tested base release instead of code from the bleeding edge? There's certainly a need for maintenance release, and IMHO the best way to manage them is with maintenance branches. > - Only one jar file (unless it bigger than 2 MB) What about people that just want to depend on our tools that work on top of the JCR API? Should they be required to pull in all of Jackrabbit as a dependency even if they work against some other repository? A single release artifact also doesn't solve the api versioning issue raised by Felix. BR, Jukka Zitting
