I would love to see 1.0, and the sooner the better. At Relevance we are doing real work in Clojure today.
As for wish list I would love to see improvements to the development process: * move from svn to git * move regression tests from contrib into clojure itself But neither of these need necessarily to block 1.0 IMO. When I release software that depends on Clojure I pin it to a commit number, not to a named release. For me the named release is more about public recognition than anything else. Cheers, Stu P.S. Git is to svn as functional languages are to mutable languages. Git repositories are immutable data structures, and repos-local pointers such as HEAD are like atoms. It would be interesting to see Clojure's data structures have a canonicalized serialization and play around with content addressability. > When we release software that depends on Clojure we don't care about > numbered releases at all -- we will run regression tests of our own > production app against the Clojure and contrib repositories and pin > our releases to a commit number, not a specif > > People (and not just book authors :) often ask - whither 1.0? [Ok, > maybe they don't use 'whither']. The fact remains, some people want a > 1.0 designation, and I'm not unwilling, providing we as a community > can come to an understanding as to what that means, the process it > implies, and the work it will require (and who will do it). Here are > some of the relevant issues, IMO: > > - Stability/completeness/robustness > > This is mostly about - does it work? Is it relatively free of bugs? Is > it free of gaping holes in core functionality? I think Clojure is in a > pretty good place right now, but am obviously biased. This in no way > implies there isn't room for improvement. > > - API stability > > With the semantic changes of fully lazy sequences behind us, I think > the syntax and semantics of existing functions is largely stable. > > - Development process stability > > Currently all new work (fixes and enhancements) occurs in trunk. > There's no way to get fixes without also getting enhancements. I think > this is the major missing piece in offering stable numbered releases. > While I've cut a branch for each of the prior two releases, no one has > ever submitted a bugfix patch for either. If people are going to want > to work with a particular release version for an extended period of > time, someone (other than me) will have to produce patches of (only!) > fixes from the trunk for the release branch, and occasionally produce > point releases (1.0.x) from that branch. I'd like to continue to do > the bulk of my work in trunk, without messing anyone up or forcing > everyone to follow along. > > - Freedom from change > > Numbered releases are most definitely not about absence of change in > general. There are more things I want to add and change, and there > will be for some time. That will keep Clojure a living language. 1.0 > or any numbered release can't and won't constitute a promise of no > further change. But there are different kinds of change, changes that > fix bugs and changes that add new capabilities or break existing code. > People need to be able to choose the type of change they can tolerate, > and when to incur it. > > - Perception > > Obviously, a 1.0 designation impacts perception. I am not interested > in pursuing it just to influence perception, but rather to > (collectively) acknowledge a milestone in usability and stability. > However there may be other perceptions, good/bad or simply wrong (e.g. > that Clojure is "finished"). Will the general perception engendered > by 1.0 be met in the large, or a mismatch? > > What does 1.0 mean to you? Are we there yet? Any recommendations for > the organization of the release branches, patch policy etc? > > Feedback welcome, > > Rich > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
