On Apr 17, 8:21 am, Rich Hickey <richhic...@gmail.com> wrote:
> Thanks all for the feedback. One impression I get is that it seems the
> existing community is getting along ok on trunk, so perhaps we also
> need to consider those not yet using Clojure, possibly even because of
> a lack of 1.0.
>
> I joked about book authors, but I'd like to make it clear that I think
> it is very important that Stuart's book correspond to a release of
> Clojure. It would be huge for newcomers coming to Clojure find a book
> that says "Covers Clojure 1.0", and a compatible download for 1.0.x
> with the latest fixes.
>
> Stuart has worked hard on tracking the latest changes, as have I in
> trying to get in those changes that would be breaking as soon as I
> could before 1.0. I'm presuming it's not too late to get "Covers
> Clojure 1.0" in there (Stuart?), and, if so, it is a factor in this
> decision.
>
> I'll also add that there is plenty more I'd like to do, and as soon as
> I get into that trunk will again be changing rapidly. There simply has
> to be a branch for fixes only.
>
> As to the feedback:
>
> A library management system seems like a tall order for a language
> 1.0. It is certainly an interesting and useful pursuit, but given the
> variety of approaches and opinions therein, it seems a bit out in
> front of us. Advantages of Maven vs Ivy vs whatever should be
> separate. Git is not going to happen any time soon, great as it may
> be, given the current lack of infrastructure (google code) and tools
> support. Is there some respect in which this impacts the core? It
> would seem dangerous to marry any single approach in the language
> itself.
>
> A deprecation policy is a good idea. Backward compatibility mode is
> unlikely.
>
> As for tests, there are tests in:
>
> http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
>
> Anyone who wants more tests can contribute them.
>
> 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 think you could call it 1.0 now, if you're ready for the kinds of
expectations and bug reports that version brings with it.I don't think
it is any kind of barrier to further experimentation and development.
I do think that you're right to think that slapping a 1.0 label on it
means there should be some specific revision that people can download
called "1.0", and reasonably expect to get a specific, stable set of
features.
Clozure Associates went through this exact discussion a couple years
ago when it considered whether to designate the next release of
OpenMCL (now called CCL) as "1.0". It had pretty much the same set of
considerations. In the end, Clozure did adopt the "1.0" designation,
and I think on the whole the effect has been positive; it helped bring
the general perception of CCL's maturity closer to the reality.
Go ahead and call Clojure "1.0", when you're ready to make sure
there's a "1.0" release people can download, and when you're ready for
an influx of bug reports from new users who are confused by foiled
preconceptions.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
