On Fri, Apr 17, 2009 at 9:21 AM, Rich Hickey <richhic...@gmail.com> wrote:
> <snip> > > As for tests, there are tests in: > > > http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src/clojure/contrib/test_clojure > > Anyone who wants more tests can contribute them. > I think what would be useful, though, is to have a test suite with the Clojure code. That way the suite is branched with the Clojure code. If a 1.0 branch is created in the Clojure code, then how does the test-clojure suite relate to that? Would there be a 1.0 branch made of clojure-contrib, too? Would there be any assurance that version X of the test-clojure suite can be run against version X.Y of Clojure to verify there were no regressions? And on clojure-contrib in general, I think maybe there needs to be a better definition of what its scope is. Just because I have cool-whizz-bang Clojure library does it mean that cool-whizz-bang should be made part of clojure-contrib? clojure-contrib is for "user contributed code", but just any code at all? As others have mentioned, clojure-contrib seems to include some things that might warrant separate projects (like ClojureScript and ClojureCLR). I don't see a problem with people creating Clojure libraries and distributing them apart from clojure-contrib, but of course as soon as the code starts to get distributed in different channels, you have the dependency management issue. (ugh!) Overall, I'm getting feature requests (more change!) and not a strong > drive for 1.0 stability. If you feel otherwise, please speak up. > Otherwise, my conclusion is that 1.0 may be more important for not-yet- > users wary of working from source. > I don't think that feature requests preclude a 1.0 release. I think all that is warranted is partitioning the feature requests into releases. 1.0 will include x, y, and z (and are labeled with Release-1.0 in the issue tracker). 2.0 will include a, b, and c (and are labeled so). As soon as x, y, and z are completed, then you cut a 1.0 release. (*brushes off hands* "Now we start on 2.0.") Of course you would have the flexibility (within reason) of shifting features to earlier or later releases. If a bug fix comes in, and it is determined that it should be backported from trunk to the 1.0 branch, then label it so in the issues tracker, and the 1.0 release captain can modify the test suite, and cut a 1.0.1 release. There is already a list of "Primary Contributors" on the clojure.org site. I nominate them as release captains :). I don't think that Rich needs to be bothered with that sort of thing. I hesitate to say this, but if no one else will do it, then I'll volunteer, since I got a pretty good idea of the inner workings of Clojure with my Terracotta work. All that said, Rich, don't feel rushed into making decisions about this. If you're not comfortable, cutting a 1.0 release and starting the whole release management process, then don't. It's getting close, but maybe it's not time just yet. However, I don't think it's a matter of having to stop progress, but just to create check points along the way, and to give people that psychological ease of seeing 1.0. Paul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
