2009/5/4 Phil Hagelberg :
>
> On May 2, 1:02 am, Laurent PETIT wrote:
>> > > Note: I strongly suggest that the clojure.version.interim property
>> > > remains true in svn, so that it's not possible to inadvertently
>> > > release a version "too early".
>>
>> > Just to clarify - are you suggestin
On May 2, 1:02 am, Laurent PETIT wrote:
> > > Note: I strongly suggest that the clojure.version.interim property
> > > remains true in svn, so that it's not possible to inadvertently
> > > release a version "too early".
>
> > Just to clarify - are you suggesting I should just change
> > version.p
2009/5/1 Rich Hickey
>
>
>
> On Apr 26, 6:54 pm, Laurent PETIT wrote:
> > I've created issue 110 with the patch attached in clojure's google code
> project.
> >
> >
> > Note: I strongly suggest that the clojure.version.interim property
> > remains true in svn, so that it's not possible to inadve
On Apr 26, 6:54 pm, Laurent PETIT wrote:
> I've created issue 110 with the patch attached in clojure's google code
> project.
>
>
> Note: I strongly suggest that the clojure.version.interim property
> remains true in svn, so that it's not possible to inadvertently
> release a version "too earl
Dear Clojurians,
Am 28.04.2009 um 15:26 schrieb Rich Hickey:
Feedback welcome,
I updated my Clojure+Ivy patch to use the new
version information. Using the publish target is
only possible on none-interim releases and
publishes the given version.
publish-local will use SVNAnt to extract the
c
Now that the files are versioned, should ant clean do
* 1. a "brute force" equivalent of rm clojure*.jar in %CLOJURE_INSTALL%
* 2. or just try to delete clojure jars with names equal to the
current values in version.properties
I prefer 1., since with 2. if version numbers have changed in
version
On Apr 28, 9:41 am, Laurent PETIT wrote:
> Hi,
>
> 2009/4/28 Rich Hickey :
>
>
>
> > On Apr 27, 5:01 pm, Laurent PETIT wrote:
> >> New patch with corrections posted to google code,
>
> > That patch has been applied. I recommend everyone who is able to
> > please try out the latest version from
2009/4/28 Laurent PETIT :
>
> 2009/4/28 Marko Kocić :
>>
>> Shouldn't "ant clean" remove all generated files, including jars from
>> the source tree?
>
> I also asked this to myself, but it was the previous behaviour and I
> didn't want to do more than one thing in the patch.
"ant clean" in the c
2009/4/28 Marko Kocić :
>
> Shouldn't "ant clean" remove all generated files, including jars from
> the source tree?
I also asked this to myself, but it was the previous behaviour and I
didn't want to do more than one thing in the patch.
--~--~-~--~~~---~--~~
You
Shouldn't "ant clean" remove all generated files, including jars from
the source tree?
--~--~-~--~~~---~--~~
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
On Apr 28, 2009, at 15:26, Rich Hickey wrote:
> That patch has been applied. I recommend everyone who is able to
> please try out the latest version from SVN - this will become a
> release candidate.
After modifying my build scripts to take into account the new name of
the jar file, all the bu
Hi,
2009/4/28 Rich Hickey :
>
>
>
> On Apr 27, 5:01 pm, Laurent PETIT wrote:
>> New patch with corrections posted to google code,
>>
>
> That patch has been applied. I recommend everyone who is able to
> please try out the latest version from SVN - this will become a
> release candidate. The patc
On Apr 27, 5:01 pm, Laurent PETIT wrote:
> New patch with corrections posted to google code,
>
That patch has been applied. I recommend everyone who is able to
please try out the latest version from SVN - this will become a
release candidate. The patch generates jar files with version numbers
New patch with corrections posted to google code,
regards,
--
laurent
2009/4/27 Laurent PETIT :
> I've created issue 110 with the patch attached in clojure's google code
> project.
>
> Hi Rich, Howard,
>
> I'll answer to both at the same time, trying to reconcile things a bit.
>
> Howard, my
Rich, refer to the patch described by Stephen Gilardi at
http://groups.google.com/group/clojure/msg/2b7dd55d9f766125 (which
makes it possible to run Clojure under z/OS).
Based on Steve and Laurent PETIT's comments in that thread, I gather
that the UTF-8 vs platform-default issue has been around a
I've created issue 110 with the patch attached in clojure's google code project.
Hi Rich, Howard,
I'll answer to both at the same time, trying to reconcile things a bit.
Howard, my first patch was already along the lines of what you
described below, I think (concerning the fact to use ant to ge
On Apr 26, 9:18 am, lpetit wrote:
> On 26 avr, 15:04, Rich Hickey wrote:
>
> > On Apr 24, 1:57 pm, Howard Lewis Ship wrote:
>
> > > Another option is for the version number to be in build.xml, and for
> > > it to generate a runtime file (so that Clojure can know its own
> > > version number)
On 26 avr, 15:04, Rich Hickey wrote:
> On Apr 24, 1:57 pm, Howard Lewis Ship wrote:
>
> > Another option is for the version number to be in build.xml, and for
> > it to generate a runtime file (so that Clojure can know its own
> > version number) and set the version number inside a generated p
On Apr 24, 1:57 pm, Howard Lewis Ship wrote:
> Another option is for the version number to be in build.xml, and for
> it to generate a runtime file (so that Clojure can know its own
> version number) and set the version number inside a generated pom.xml.
> You can use Ant resource copying with
Another option is for the version number to be in build.xml, and for
it to generate a runtime file (so that Clojure can know its own
version number) and set the version number inside a generated pom.xml.
You can use Ant resource copying with filters to accomplish both
these goals.
On Thu, Apr 23
Laurent PETIT a écrit :
> 2009/4/24 Christophe Grand :
>
>> Konrad Hinsen a écrit :
>>
>>> What I miss most for a 1.0 release is some idea of how future changes
>>> will be handled, and what Clojure users can safely count on. For
>>> example, every new function added to clojure.core will b
2009/4/24 Christophe Grand :
>
> Konrad Hinsen a écrit :
>> What I miss most for a 1.0 release is some idea of how future changes
>> will be handled, and what Clojure users can safely count on. For
>> example, every new function added to clojure.core will break code
>> that has chosen to use the s
Konrad Hinsen a écrit :
> What I miss most for a 1.0 release is some idea of how future changes
> will be handled, and what Clojure users can safely count on. For
> example, every new function added to clojure.core will break code
> that has chosen to use the same name for something else. Wh
On Apr 23, 11:24 am, Laurent PETIT wrote:
> 2009/4/23 Rich Hickey :
>
>
>
> > On Apr 22, 12:41 pm, Laurent PETIT wrote:
> >> 2009/4/22 Rich Hickey :
>
> >> > [...]
> >> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>
> >> > for interim versions and
>
> >> > {:major 1, :
2009/4/23 Rich Hickey :
>
>
>
> On Apr 22, 12:41 pm, Laurent PETIT wrote:
>> 2009/4/22 Rich Hickey :
>>
>> > [...]
>> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>>
>> > for interim versions and
>>
>> > {:major 1, :minor 0, :incremental 0}
>>
>> > for releases. :interim
On Apr 22, 12:41 pm, Laurent PETIT wrote:
> 2009/4/22 Rich Hickey :
>
> > [...]
> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>
> > for interim versions and
>
> > {:major 1, :minor 0, :incremental 0}
>
> > for releases. :interim tracks the SNAPSHOT segment of the versi
I think you can keep the version number in the pom (there's a
element at the top).
It is pretty easy to access the POM version from Ant; from there you
can create a file containing the version number, and have Clojure read
that file at startup. However, this starts getting into the world of
requ
2009/4/22 Rich Hickey :
> [...]
> {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>
> for interim versions and
>
> {:major 1, :minor 0, :incremental 0}
>
> for releases. :interim tracks the SNAPSHOT segment of the version
> string.
> [...]
> I don't mind the build producing cloj
Daniel Jomphe wrote:
> Rich Hickey wrote:
> > I don't mind the build producing clojure-1.0.0.jar etc, but it doesn't
> > now. The master build is Ant. Where is the best place to put the
> > version info so it can be leveraged by Ant, Maven and the clojure core
> > runtime in order to produce *cloj
Rich Hickey wrote:
> I don't mind the build producing clojure-1.0.0.jar etc, but it doesn't
> now. The master build is Ant. Where is the best place to put the
> version info so it can be leveraged by Ant, Maven and the clojure core
> runtime in order to produce *clojure-version* ?
>
> What changes
OOooops sorry, I mistook "qualifier" for "classifier",
:qualifier seems totally appropriate here, sorry for the noise,
--
Laurent
2009/4/22 Laurent PETIT :
> Hi,
>
> 2009/4/22 Rich Hickey :
>> [...]
>> {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>> [...]
>> Possible
>>
Hi,
2009/4/22 Rich Hickey :
> [...]
> {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
> [...]
> Possible
> values of :qualifier include :rc, :beta etc,
> and :interim will be true for non-release builds.
I don't think :qualifier is used correctly here (at least if you want
to
On Apr 21, 12:18 pm, Daniel Jomphe wrote:
> Paul Stadig wrote:
> > Others have commented on the whole groupId, artifactId, etc., etc. But in
> > terms of the parts of the version number, they are named
> > ..- as documented here:
>
> >http://www.sonatype.com/books/maven-book/reference/pom-relat
2009/4/21 Daniel Jomphe :
>
> Laurent PETIT wrote:
>> > version: 1.0.0-rc1-SNAPSHOT
>> > yields: clojure-1.0.0-rc1-.jar
>> > (and ...-slim.jar, ...-sources.jar)
>>
>> There it is. But why having "" in the name of the jar,
>> shouldn't it just be "SNAPSHOT" (as far as I remember) ?
>>
Laurent PETIT wrote:
> > version: 1.0.0-rc1-SNAPSHOT
> > yields: clojure-1.0.0-rc1-.jar
> > (and ...-slim.jar, ...-sources.jar)
>
> There it is. But why having "" in the name of the jar,
> shouldn't it just be "SNAPSHOT" (as far as I remember) ?
>
> That is:
>
> { :major 1 :minor 0 :i
Hi,
2009/4/21 Daniel Jomphe :
>
> version: 1.0.0-rc1-SNAPSHOT
> yields: clojure-1.0.0-rc1-.jar
> (and ...-slim.jar, ...-sources.jar)
There it is. But why having "" in the name of the jar,
shouldn't it just be "SNAPSHOT" (as far as I remember) ?
That is:
{ :major 1 :minor 0 :increm
Paul Stadig wrote:
> Others have commented on the whole groupId, artifactId, etc., etc. But in
> terms of the parts of the version number, they are named
> ..- as documented here:
>
> http://www.sonatype.com/books/maven-book/reference/pom-relationships-...
Thanks for the info.
So I was wrong in
On Sat, Apr 18, 2009 at 5:34 AM, Isak Hansen wrote:
>
> On Thu, Apr 16, 2009 at 6:53 PM, Rich Hickey wrote:
>>
>> Feedback welcome,
>>
>
> 1. I'd like to see a road map of sorts; plans for where Clojure will
> be going with the next couple of releases.
>
> 2. Clojure-contrib -cleanup
> - Move t
On Mon, Apr 20, 2009 at 8:52 PM, Rich Hickey wrote:
> On Apr 20, 2009, at 7:02 PM, Antony Blakey wrote:
> > On 21/04/2009, at 5:12 AM, Laurent PETIT wrote:
> >
> >> { :major 1 :minor 0 :release 0 :status :SNAPSHOT }
> >> then
> >> { :major 1 :minor 0 :release 0 :status :RC1 } (release candidate
Laurent PETIT wrote:
> I have not followed maven2 concerning this "qualifier" thing.
Right. The first (small) part of my post, which referred to yours, was
strictly about versioning, and specifically about the end of the
version string, related to snapshots.
Then I addressed the classifier as an
2009/4/21 AndrewC. :
>
> On Apr 21, 1:52 am, Rich Hickey wrote:
>
>>
>> I'm unfamiliar with the POM version coordinate system - any hints?
>>
>> Rich
>
> 1 Pager on coordinates from the 'definitive guide'
>
> http://www.sonatype.com/books/maven-book/reference/simple-project-sect-maven-coordinates
On Apr 21, 1:52 am, Rich Hickey wrote:
>
> I'm unfamiliar with the POM version coordinate system - any hints?
>
> Rich
1 Pager on coordinates from the 'definitive guide'
http://www.sonatype.com/books/maven-book/reference/simple-project-sect-maven-coordinates.html
--~--~-~--~~
Daniel,
I have not followed maven2 concerning this "qualifier" thing.
Would it be corrrect to say that, to further extend you examples, one
the qualifiers could be "slim", since clojure ant already has such a
target.
Or would a "slim" jar of clojure have to had another artifactId ? (I
don't thi
For a 1.0 release I'd love to see some support for JDK annotations
somehow, at both the gen-class and method level at least.
Mark
On Fri, Apr 17, 2009 at 4:53 AM, Rich Hickey wrote:
> This is mostly about - does it work? Is it relatively free of bugs? Is
> it free of gaping holes in core funct
Rich Hickey wrote:
> I'm unfamiliar with the POM version coordinate system - any hints?
Maven takes the version as whatever-formatted string, but recognizes a
conventional (.endsWith "1.0.0-SNAPSHOT" "-SNAPSHOT"), like described
by Laurent PETIT. So "whatever-SNAPSHOT" means we're going someday t
On 21/04/2009, at 10:51 AM, Antony Blakey wrote:
> On 21/04/2009, at 10:22 AM, Rich Hickey wrote:
>
>> I'm unfamiliar with the POM version coordinate system - any hints?
>
> My comment was in support of Laurent's proposal. I'm a relative
> maven newb, but this is my take:
>
> POMs use the conc
On 21/04/2009, at 10:22 AM, Rich Hickey wrote:
> I'm unfamiliar with the POM version coordinate system - any hints?
My comment was in support of Laurent's proposal. I'm a relative maven
newb, but this is my take:
POMs use the concept of a coordinate, which is
::: to identify a particular
On Apr 20, 2009, at 7:02 PM, Antony Blakey wrote:
>
>
> On 21/04/2009, at 5:12 AM, Laurent PETIT wrote:
>
>> To give you more ideas, there is a convention in tools like maven/ivy
>> that when you're starting the hack on a branch targeting some version
>> M.m.r , you immediately rename the place
Laurent PETIT wrote:
> > I'd suggest calling :release something else, like :revision
> > or :patch.
> I like the term "service" used in Eclipse terminology:
> "the service segment indicates bug fixes"
>
> (The numbering scheme for Eclipse uses major, minor, service and
> qualifier : "the qualifier
On 21/04/2009, at 5:12 AM, Laurent PETIT wrote:
> To give you more ideas, there is a convention in tools like maven/ivy
> that when you're starting the hack on a branch targeting some version
> M.m.r , you immediately rename the place in code where you maintain
> the version number by appending
2009/4/20 Rich Hickey :
> If there is just a (def *version* {:major 1 :minor 0 :release 0})
>
> my questions are:
>
> What happens after release to keep subsequent interim versions from
> having the same 'version' as a release? Should we have a :status
> attribute that is :release for releases an
2009/4/20 Stuart Sierra
>
> On Apr 20, 1:48 pm, Rich Hickey wrote:
> > I imagine a (clojure-version) function returning:
> >
> > {:major 1 :minor 0 :release 0}
>
> I'd suggest calling :release something else, like :revision
> or :patch. "release" sounds like a bigger number than major/minor.
>
Stuart Sierra writes:
> On Apr 20, 1:48 pm, Rich Hickey wrote:
>> I imagine a (clojure-version) function returning:
>>
>> {:major 1 :minor 0 :release 0}
>
> I'd suggest calling :release something else, like :revision
> or :patch. "release" sounds like a bigger number than major/minor.
> Other
On Apr 20, 1:48 pm, Rich Hickey wrote:
> I imagine a (clojure-version) function returning:
>
> {:major 1 :minor 0 :release 0}
I'd suggest calling :release something else, like :revision
or :patch. "release" sounds like a bigger number than major/minor.
Other than that, makes sense to me.
Maybe
Rich Hickey writes:
> If there is just a (def *version* {:major 1 :minor 0 :release 0})
>
> my questions are:
>
> What happens after release to keep subsequent interim versions from
> having the same 'version' as a release? Should we have a :status
> attribute that is :release for releases and :
On Apr 17, 5:21 pm, Tom Faulhaber wrote:
> Tom's 2 cents:
>
> I think Clojure is basically ready to go to 1.0. I like the idea of
> having a book about Clojure 1.0 go hand in hand with the release.
>
> While I agree that the library management problem is too hard for a
> 1.0 release (and also l
For a 1.0 release, I think that having a number that we can point at
and say "this software will work with that version of the language" is
important. I think a little bit of polish wouldn't be bad either: I
saw that Scala ships with bash and batch scripts to launch scala and
scalac. I think hav
On Apr 17, 2:47 pm, revoltingdevelopment
wrote:
> Aside from that, I think you are right about the psychology of
> language adoption and book-buying. Declaring 1.0 to coincide with the
> content and publication date of Stuart's book is just an excellent
> idea, regardless of all the other issue
On Apr 17, 2:47 pm, revoltingdevelopment
wrote:
> Aside from that, I think you are right about the psychology of
> language adoption and book-buying. Declaring 1.0 to coincide with the
> content and publication date of Stuart's book is just an excellent
> idea, regardless of all the other issues
On Apr 18, 3:15 am, John Newman wrote:
> > I do not agree with John Newman that the Java standard library
> > should be the Clojure standard library.
>
> I'm not saying that. I'm saying that:
>
John, I misunderstood what you were trying to say. My apologies!
There seems to be some agreement
On 18/04/2009, at 5:38 PM, Konrad Hinsen wrote:
>
> On 18.04.2009, at 01:13, Dan wrote:
>
>> do you prefer to have some clojure users united against subversion,
>> or divided by Rich not having chosen their preferred DVCS
>> (Mercurial users vs Git users, not sure whether clojure needs those
>>
On Thu, Apr 16, 2009 at 6:53 PM, Rich Hickey wrote:
>
> Feedback welcome,
>
1. I'd like to see a road map of sorts; plans for where Clojure will
be going with the next couple of releases.
2. Clojure-contrib -cleanup
- Move the clojure test suite to clojure itself
- Move 'worthy' libraries fro
Well, perhaps if str-utils becomes the universal standard for string
operations, it would be rolled into Clojure come 2.0?
On Sat, Apr 18, 2009 at 2:58 PM, Konrad Hinsen wrote:
>
> On 18.04.2009, at 12:15, John Newman wrote:
>
> > 2) One way to maintain Clojure's flexibility would be if it were
>
I'm eager to see Clojure turn 1.0 because it is a fantastic language
that deserves to be even more popular than it already is. I believe it
is time to put the message out there that clj has made the journey
from "something to toy with" to "a serious language" or even "the next
big thing". Clojure
On 18.04.2009, at 12:15, John Newman wrote:
> 2) One way to maintain Clojure's flexibility would be if it were
> like what the kernel is to a Linux distribution. What if every
> distribution had to use the same standard set of packages? The
> Linux ecosystem is much richer today because t
> I do not agree with John Newman that the Java standard library
> should be the Clojure standard library.
>
I'm not saying that. I'm saying that:
1) Requiring Java's standard library on every system is unfortunate enough
-- it's too big for some of the smaller devices coming out now. And,
2) O
On 18.04.2009, at 01:13, Dan wrote:
> do you prefer to have some clojure users united against subversion,
> or divided by Rich not having chosen their preferred DVCS
> (Mercurial users vs Git users, not sure whether clojure needs those
> kinds of nonsense internal wars in the community
I'm a relatively new user of Clojure and thought I'd add my
perspective to the pile regarding what I would expect from a 1.0
release.
My biggest frustrations with Clojure as a newcomer were:
1. Setting it up so it was easy to use across projects
2. The API documentation
While the documentation
On 18/04/2009, at 11:51 AM, mikel wrote:
>> It's not clear how to use the stuff in clojure-contrib, which
>> certainly seems like the 'standard library' of useful tools that
>> makes
>> clojure into something other than a lispy language using Java
>> libraries.
>
>
> This is a good point. Us
2009/4/18 Laurent PETIT :
> [snip] at least Rich disagrees (and unanimity
> implies "all people", not even one let apart).
> And you can also count on me, Meikel Brandmeyer (author of VimClojure),
> maybe Paul Drummond (?) that pointed to python's decision to use Mercurial.
I have only used SVN m
On Apr 17, 9:21 am, Rich Hickey wrote:
> A library management system seems like a tall order for a language
> 1.0. It is certainly an interesting and useful pursuit, but given the
> variety of approaches and opinions therein, it seems a bit out in
> front of us.
Yes. I retract my request. :) B
Hi Rich,
Every decision is a balance and will have good and bad aspects, of course.
In the good aspects of releasing a 1.0 quickly, is the fact that (coupled
with Stu's book release) I can try to more succesfully promote clojure
internally in my company (Ah, these psychological issues ;-).
In th
2009/4/18 Laurent PETIT
>
>
>
> Rich is the main maintainer of clojure source, just let him use the DVCS he
> wants. And really, it's not that difficult to checkout a working copy of
> svn, hack on it, and do a svn diff > mypatch.diff to send him when ready (so
> more complex management cases may
2009/4/18 Dan
>
>
> On Fri, Apr 17, 2009 at 4:29 PM, Laurent PETIT wrote:
>
>> I guess there's really no perfect solution here :-(
>>
>> The question is :
>>
>> do you prefer to have some clojure users united against subversion, or
>> divided by Rich not having chosen their preferred DVCS (Mercur
On Apr 17, 8:31 pm, Antony Blakey wrote:
> As a lurker, considering Clojure for a project, the thing that is
> giving me pause isn't 1.0 per se, but the combination of a good
> library mechanism and documentation. I have Stuart's book, and I agree
> in the strongest possible terms that it
As a lurker, considering Clojure for a project, the thing that is
giving me pause isn't 1.0 per se, but the combination of a good
library mechanism and documentation. I have Stuart's book, and I agree
in the strongest possible terms that it should be a book explicitly
about a stable Clojur
As with any decision, it will be impossible to please everyone. I
think the Git vs Subversion talk is way off topic at this point, but
to each his own.
Rich, I think it really depends on what *YOU* want Clojure to be. If
you want to take a Haskell like approach and "avoid success at all
costs"
On Fri, Apr 17, 2009 at 4:29 PM, Laurent PETIT wrote:
> I guess there's really no perfect solution here :-(
>
> The question is :
>
> do you prefer to have some clojure users united against subversion, or
> divided by Rich not having chosen their preferred DVCS (Mercurial users vs
> Git users, not
My .02 on the version control issue:
All of them work. Some are easier to use than others. There are
successful projects that use just about all of them. It's personal
preference. Rich is going to be doing most the contributing, let him
choose the VCS.
Period.
On Apr 17, 4:29 pm, Laurent PETIT
2009/4/17 Tom Faulhaber :
> While I agree that "what is clojure.contrib?" is a pretty big issue, I
> think we could leave it a little fuzzy for a while longer. One thing
> we should probably do is do a real comparison of how we stack up
> against python's "batteries included" model and see how we
2009/4/17 Laurent PETIT :
> do you prefer to have some clojure users united against subversion, or
> divided by Rich not having chosen their preferred DVCS (Mercurial users vs
> Git users, not sure whether clojure needs those kinds of nonsense internal
> wars in the community )
I agree the la
Tom's 2 cents:
I think Clojure is basically ready to go to 1.0. I like the idea of
having a book about Clojure 1.0 go hand in hand with the release.
While I agree that the library management problem is too hard for a
1.0 release (and also largely separable), it would be nice to see the
software
On Fri, Apr 17, 2009 at 6:21 AM, Rich Hickey wrote:
> Overall, I'm getting feature requests (more change!) and not a strong
> drive for 1.0 stability. If you feel otherwise, please speak up.
> Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> users wary of working from sou
I guess there's really no perfect solution here :-(
The question is :
do you prefer to have some clojure users united against subversion, or
divided by Rich not having chosen their preferred DVCS (Mercurial users vs
Git users, not sure whether clojure needs those kinds of nonsense internal
wars i
Rich says "Git is not going to happen any time soon, great as it may
be, given the current lack of infrastructure (google code) and tools
support."
I'm curious as to why github isn't a viable alternative to google
code? Now that it has issue tracking, I don't see the advantages of
choosing goog
On Thu, Apr 16, 2009 at 11:53 AM, Rich Hickey wrote:
[...]
>
> - 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 number
On Apr 17, 8:21 am, Rich Hickey wrote:
> Thanks all for the feedback. One impression I get is that it seems the
> existing community is getting along ok on trunk, so perhaps we also
> need to consider those not yet using Clojure, possibly even because of
> a lack of 1.0.
>
> I joked about book
Rich,
A list of the things you know you want to add or change would be
useful to this discussion. For all we know, there could be a game-
changer on that list that would suggest holding off on 1.0.
Aside from that, I think you are right about the psychology of
language adoption and book-buying.
To me, major version numbers means no more nor less than a marker
pointing to a stable, consistent release that can be easily referred
to consistently by everyone. It doesn't mean that there can't be
major, breaking changes for 2.0 (or even 1.5, whatever). I don't even
care what features are in th
> Overall, I'm getting feature requests (more change!) and not a strong
> drive for 1.0 stability. If you feel otherwise, please speak up.
> Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> users wary of working from source.
My thought was that I very much like that you d
I vote for 1.0 as soon as possible. Seems stable to me. I'm working on a
chat application and when we moved to fully lazy sequences, still none of my
code broke.
I vote no on making contrib the "Standard Library." The Java Standard
Library is large enough. I would like contrib to be easier to
On Apr 17, 9:21 am, Rich Hickey wrote:
*snip*
>Git is not going to happen any time soon, great as it may
> be, given the current lack of infrastructure (google code) and tools
> support. Is there some respect in which this impacts the core? It
> would seem dangerous to marry any single approach i
I would love to see 1.0, and the sooner the better. At Relevance we
are doing real work in Clojure today.
As for wish list I would love to see improvements to the development
process:
* move from svn to git
* move regression tests from contrib into clojure itself
But neither of these need n
On Fri, Apr 17, 2009 at 9:21 AM, Rich Hickey wrote:
>
>
> As for tests, there are tests in:
>
>
> http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src/clojure/contrib/test_clojure
>
> Anyone who wants more tests can contribute them.
>
I think what would be useful, though, is to
Strangely enough, for me version 1.0 would mean the version of Clojure
described in the book "Programming Clojure" by Stuart Halloway.
It would be a version that I could download directly even though newer
versions would appear afterward so the book and the Clojure version
are consistent with one
a) Stability ? Looks pretty fine to me up to now...
b) Getting 1.0 out ? Absolutely needed to increase the level of
acceptance of Clojure. Future releases will have to clearly documented
as to what they fix,
what changes have been done to the language itself and what it may
break in user code.
I feel the urge to drop a couple more pennies into this thread.
Trunk should NOT be used for day-to-day development and
experimentation. There should be a branch for that.
Trunk should NEVER be broken. Comprehensive tests need to run and pass
on the development branch before those changes are me
One possible approach that just occurred to me waking up this morning is to
just do it. The very idea that now is a good time to ask the question is a
milestone. 1.0 marks the time that the question was asked as to what it
would take for there to be a 1l0! That was a typo, I meant 1.0, but why u
Thanks all for the feedback. One impression I get is that it seems the
existing community is getting along ok on trunk, so perhaps we also
need to consider those not yet using Clojure, possibly even because of
a lack of 1.0.
I joked about book authors, but I'd like to make it clear that I think
i
2009/4/16 Rich Hickey :
> What does 1.0 mean to you?
I just wanted to give some thoughts on what I think are the main
points coming from this discussion. It seems like most agree that
"Clojure the language" is ready for a 1.0 release (and all that comes
with it). The main issues are A) choice o
1 - 100 of 121 matches
Mail list logo
