On Thu, Apr 16, 2009 at 9:53 AM, 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.
Version numbering should reflect stability and compatibility. Clojure x.y.z z increments when a release changes functionality but not (public) APIs. y increments when a release adds new public APIs. x increments when public APIs change in a non-compatible way. People should have the expectation that an upgrade from 1.0.2 to 1.0.3 should be painless (and you should be able to back down from 1.0.3 to 1.0.2 without any compilation errors). An upgrade from 1.0.3 to 1.1.0 may not be reversable (if you start using new APIs in 1.1.0, your code won't compile is you revert to 1.0.3). However, this is very hard to achieve in practice (so far we haven't pulled this off for Tapestry); just knowing how a particular change affects the y or z digit takes experience. In addition, there's a drive from end users who want pre-compiled snapshots of versions short of a fully endorsed release. That's one of the reasons I've put some effort into the Clojure nightly builds and Maven repository: to allow people to track the latest without building it themselves, or asking Rich to make more frequent releases. Clojure has an advantage here that functions, rather than objects, are extremely fine grained. In addition, macros and multimethods allow API compatibility to be maintained even as new features are added. Finally, my experience with final releases is that they rarely are. Drawing a line in the sand and saying "this is the 1.0 release" usually results in a frantic batch of patch releases. Instead, release a candidate, say "1.0.1". If you find bugs, release a new "1.0.2". When bugs stop being deal-busters, announce that "1.0.2" is the GA release. In other words, let a release prove itself before being anointed the final release. Having a fixed release version number is no different than having a fixed release date: those are impositions by marketing, not an engineering decision. I think there is a definite need, however, to ** get tests into clojure-lang **. The tests will be the best way to determine how a change affects compatibility. Regressions are very hard to predict, and I don't trust myself to identify which changes will break client code, and which will not ... short of having a test to represent client code. The lack of tests and the sorry state of Java code documentation are daunting to many, including myself. Rich is obviously brilliant, but any successful project has to scale beyond its creator. The lack of tests and documentation borders on arrogance. > > - 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? This is an important perception! > > 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 > > > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
