That is putting it quite strongly, Howard. Instead of stating the problem as a problem of arrogance, it would be better to state it as without X, you can't get Y.
Specifically, without better documentation there exists a class of users that will not use clojure and there exists a class of problems that will take a lot longer to solve than they would otherwise take with better documentation. Without more testing it will be impossible to say that any given change in subversion won't break a program. Really, this is an impossible statement anyway although I realize that tests mitigate the problem somewhat. Thus we can't use x.y.z. Every change would be just x (somewhat absurd but at least correct). Your point release theory sounds good if the use cases of your library are very will defined and tested. A programming language doesn't fit the testability coverage scenario very well as it is, well, a turing complete language and thus it would be difficult at best to prove it was working as it was before after *any* non-trivial change (difficult meaning it is unlikely anyone here is a good enough mathematician to do it in the average case). I agree that more tests would be a good thing; I personally am not going to touch clojure source without more tests that show a little more of the intent of what the code is doing. But clients of clojure *should* have sufficient tests to ensure that upgrading clojure will not present a massive problem; it is impossible for Rich or anyone else to provide this guarantee. So the question is, what level of documentation and what level of test coverage is important for a 1.0 release? What would you like to see documented and tested? I would like to see the datastructures' memory and performance bounds tested, for instance. Chris On Apr 16, 2:58 pm, Howard Lewis Ship <hls...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
