Message from discussion The Path to 1.0
Received: by 10.115.22.9 with SMTP id z9mr427148wai.28.1239918313397;
Thu, 16 Apr 2009 14:45:13 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [18.104.22.168])
by gmr-mx.google.com with ESMTP id m37si647662waf.0.2009.04.16.14.45.12;
Thu, 16 Apr 2009 14:45:12 -0700 (PDT)
Received-SPF: pass (google.com: domain of hls...@gmail.com designates 22.214.171.124 as permitted sender) client-ip=126.96.36.199;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of hls...@gmail.com designates 188.8.131.52 as permitted sender) smtp.mail=hls...@gmail.com; dkim=pass (test mode) header...@gmail.com
Received: by wf-out-1314.google.com with SMTP id 25so584747wfa.3
for <firstname.lastname@example.org>; Thu, 16 Apr 2009 14:45:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
DomainKey-Signature: a=rsa-sha1; c=nofws;
Content-Type: text/plain; charset=ISO-8859-1
Received: by 10.142.158.3 with SMTP id g3mr2960213wfe.221.1239918312140; Thu,
16 Apr 2009 14:45:12 -0700 (PDT)
Date: Thu, 16 Apr 2009 14:45:12 -0700
Subject: Re: The Path to 1.0
From: Howard Lewis Ship <hls...@gmail.com>
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. =A0Really, this is an
> impossible statement anyway although I realize that tests mitigate the
> problem somewhat. =A0Thus we can't use x.y.z. =A0Every 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. =A0A 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. =A0But 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
> So the question is, what level of documentation and what level of test
> coverage is important for a 1.0 release? =A0What would you like to see
> documented and tested?
> I would like to see the datastructures' memory and performance bounds
> tested, for instance.
> On Apr 16, 2:58=A0pm, Howard Lewis Ship <hls...@gmail.com> wrote:
>> On Thu, Apr 16, 2009 at 9:53 AM, Rich Hickey <richhic...@gmail.com> wrot=
>> > 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
>> 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". =A0If you find bugs, release a new "1.0.2". =A0When bugs st=
>> 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 **. =A0The 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, =A0changes th=
>> > 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"). =A0Will 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