On Thu, Apr 16, 2009 at 2:40 PM, chris <cnuern...@gmail.com> wrote: > > 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).
Only a small portion of the code is the language; most of Clojure is the standard library, which can be unit tested. Testability is one of the foundations of functional programming, so its painful to see no actual tests. > > 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. There are no guarantees, but there are measures you can take to inspire confidence. > > 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 > > > -- 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 -~----------~----~----~----~------~----~------~--~---
