For a 1.0 release, I think that having a number that we can point at and say "this software will work with that version of the language" is important. I think a little bit of polish wouldn't be bad either: I saw that Scala ships with bash and batch scripts to launch scala and scalac. I think having an easy way to start using Clojure like that would definitely help newcomers. Many languages ship with modes for different editors as well; it might be nice to include the more basic modes (i.e. not SLIME and Gorilla, but clojure-mode and a syntax file for vim)
Finally, I think emulating Perl's strong commitment to unit testing the language would be a beneficial thing in the long run. Cheers, Vince On Apr 16, 12:53 pm, Rich Hickey <richhic...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
