a) Stability ? Looks pretty fine to me up to now...
b) Getting 1.0 out ? Absolutely needed to increase the level of
acceptance of Clojure. Future releases will have to clearly documented
as to what they fix,
what changes have been done to the language itself and what it may
break in user code. But that's not a show stopper, it's been like that
for
years with most compilers/languages I worked with. The time to
release another "official" build may be a bit longer to bundle the list
of changes.
It does not have to be fancy but maybe the comments added to each
SVN version should be expanded a bit to be more accessible to mere
mortals.
That could be the basis for release notes. Attaching bug reports to
release notes maybe harder, I do not see how you can achieve that with
Google code.
c) Clojure is unfinished ? Well that has been the state of most software
languages and tools for years. Will new enhancements require changes to
the core ?
Maybe, maybe not. Considering the available mechanisms built in
Clojure to extend itself, I do not see why we should worry now about
this, except if
Rich has another grandiose idea in the back of head that we are not
aware of :)))) (Rich, maybe you should then consider creating another
dialect ? :))))
Considering the growing pains we faced with Java in the last 9
years, I think enhancing Clojure will be a breeze compared to the
maelstrom of JVM
bugs, compatibility issues and behaviour changes with had to deal
with.
d) Test suite ? Covering all cases is a long term task in any
programming language and just figuring out all these cases would
postponed 1.0 for months.
Adding test cases along the way is the only practical alternative.
Maybe we should go with the requirement that a bug report should include
a usable test case. That would at least reduce the work of the
person doing/integrating the fix in the code.
e) Is the current test framework fine ? Well until we think about
something else better, we should stick with it and just enrich that with
test cases.
Maybe we should adopt a test numbering that matches bug reports and
use that to update the existing test suites and track things.
No need for some heavy stuff, bare comments are enough. At least
that stuff will be documented somewhere.
f) Contrib library management ? That should be a top priority but Rich
is right getting this out in 1.0 is a tall order and people do not seem
to agree
on what should be used. Personally, I think there are enough tools
out there and inventing another one is superfluous. I can understand
why gems were created, I can understand the need for Lancet but
creating another Clojure-like maven ?
Why not use something already there and put our energy on more
Clojure centric stuff ?
g) Changing the source code management tool ? Not a priority. How many
people to we expect to play on the core ? If we say that 500 people
will make changes ok, we may have a problem with SVN and GIT might
be better at it. But I do not think we are there and I do not see that
as a great idea (having hundreds of people working on the core).
Google code does the job so far, lets build on that.
Being afraid of committing to practises/tools is worst than moving
forward. We could wait for months/years juggling with what is the best
thing to commit to. Let's learn by mistakes a bit here... Each year
there will be a greater test framework/build tool/etc... but somehow we
have to make choices now...
Rich, maybe it's time to establish, following that 1.0 release, a set of
priorities ? I think we need some dictatorship here and
you are the best candidate from my point of view.
The idea is not to put more pressure/work on your shoulders but making
sure the delegation process is efficient to make Clojure move forward.
You seem to have other concepts to integrate in Clojure and that should
remain your main responsibility but for all the other stuff you
could establish the priorities and guidelines to follow. Then the
community could tackle these things in an orderly fashion.
Consensus can be a great thing but often it costs precious time...
Luc
On Fri, 2009-04-17 at 06:21 -0700, Rich Hickey 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/clojure/contrib/test_clojure
>
> 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.
>
> Rich
>
> >
>
Luc Préfontaine
Armageddon was yesterday, today we have a real problem...
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
