The Path to 1.0 - Clojure

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion The Path to 1.0
Received-SPF: pass (google.com: domain of hls...@gmail.com designates 209.85.200.174 as permitted sender) client-ip=209.85.200.174;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=CvUbqZkEazZu3HdDlximPf/PqroSdN2KYblyBefn+sGF4zWV8NJ+mmgu5G6SUDLyZz
         5/EKL43FBDDPES3mA0ecweEipWlo4zGU9cfG2/YMCtK5pu8wctPDjl2XmLNmcsq53GNZ
         JvoVOPiyqF3dyr6tJf6n3bwgyK/Hftwl1LfqI=
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <151152aa-0e80-48aa-9c33-6d4e3184fed9@j9g2000prh.googlegroups.com>
References: <fb264386-84aa-400e-9330-364248e65...@v15g2000yqn.googlegroups.com>
	 <ecd0e3310904161358x54eb3292s4ddc08d57ecd1...@mail.gmail.com>
	 <151152aa-0e80-48aa-9c33-6d4e3184f...@j9g2000prh.googlegroups.com>
Date: Thu, 16 Apr 2009 14:45:12 -0700
Message-ID: <ecd0e3310904161445g472f2641k3ce66369d4ecd...@mail.gmail.com>
Subject: Re: The Path to 1.0
From: Howard Lewis Ship <hls...@gmail.com>
To: clojure@googlegroups.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
inspire confidence.

>
> 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.
>
> Chris
>
> 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=
e:
>>
>> > 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". =A0If you find bugs, release a new "1.0.2". =A0When bugs st=
op
>> 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=
at
>> > 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
> >
>



--=20
Howard M. Lewis Ship

Creator of Apache Tapestry
Director of Open Source Technology at Formos
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
