Re: The Path to 1.0
On May 2, 1:02 am, Laurent PETIT laurent.pe...@gmail.com 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.properties by hand, build and release the result, but never check in with clojure.version.interim=false? Yes. I think this is correct to check-in with other version attributes correctly set for the upcoming release, but keep the interim attribute to false in the svn repository, so that nobody can create an official release inadvertently. This is a fine idea for trunk, but it would be wise to check in interim=false on the revision that gets tagged as 1.0 in SVN. Congrats on the release btw; I'm very excited. -Phil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/5/4 Phil Hagelberg technoma...@gmail.com: On May 2, 1:02 am, Laurent PETIT laurent.pe...@gmail.com 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.properties by hand, build and release the result, but never check in with clojure.version.interim=false? Yes. I think this is correct to check-in with other version attributes correctly set for the upcoming release, but keep the interim attribute to false in the svn repository, so that nobody can create an official release inadvertently. This is a fine idea for trunk, but it would be wise to check in interim=false on the revision that gets tagged as 1.0 in SVN. Yes, sure, this would be fine for a tag .. if there were one ;-) Congrats on the release btw; I'm very excited. -Phil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/5/1 Rich Hickey richhic...@gmail.com On Apr 26, 6:54 pm, Laurent PETIT laurent.pe...@gmail.com 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 early. Just to clarify - are you suggesting I should just change version.properties by hand, build and release the result, but never check in with clojure.version.interim=false? Yes. I think this is correct to check-in with other version attributes correctly set for the upcoming release, but keep the interim attribute to false in the svn repository, so that nobody can create an official release inadvertently. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 26, 6:54 pm, Laurent PETIT laurent.pe...@gmail.com 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 early. Just to clarify - are you suggesting I should just change version.properties by hand, build and release the result, but never check in with clojure.version.interim=false? Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 27, 5:01 pm, Laurent PETIT laurent.pe...@gmail.com 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
in the names. It was suggested on IRC that perhaps it should also copy
the jar to their traditional (non-versioned) names, for greater
compatibility. Maven users please make sure that side of the build
works for you.
Feedback welcome,
Rich
2009/4/27 Laurent PETIT laurent.pe...@gmail.com:
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 generate
with filters from templates).
Then Rich asked if it was possible to not have to generate files. I
understand this question a little less broadly than not generate
files at all cost, but not generate files in the source code. So
that if the generation step is not followed by some tool for some
reason, things don't break - at compile time or run time -.
That's why I came up with this new version:
* a src/clj/clojure/version.properties file
* this version.properties file is the reference for version numbers.
It is on the classpath so it can be seen by clojure at runtime. It is
in a subdirectory of clojure-the-project so any tool can refer to it
relatively to the installation of clojure.
* I've added the needed code to clojure to load clojure version
number at startup time
I've also added function (clojure.core/clojure-version) that will
return a string representing the version from the structured
*clojure-version* map. The algorithm here is simple:
MAJOR.MINOR[.INCREMENT][-QUALIFIER][-SNAPSHOT]
* I've changed the ant build.xml so that it creates fully qualified
names with version attributes for the generated jars.
* Note on the :interim attribute: to protect the person who makes
releases from itself, instead of considering :interim to be true if
there is the true string in the properties file, I've made the
opposite choice: interim is true for any value other than false. So
if there is a typo in version.properties (e.g. tru instead of true),
then the release will be marked as interim, and that will not be a big
deal. In the other case, it would be a big deal if an official release
was made accidentally instead of an interim.
* finally, pom.xml file is now generated from ant as part of the
classic init step.
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.
HTH,
Feel free to use or not,
--
Laurent
2009/4/24 Howard Lewis Ship hls...@gmail.com:
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, 2009 at 8:24 AM, Laurent PETIT laurent.pe...@gmail.com
wrote:
2009/4/23 Rich Hickey richhic...@gmail.com:
On Apr 22, 12:41 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{: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 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* ?
Here a patch that allows to initialize from ant and from a file
version.properties the values in *clojure-version*.
The patch only addresses the problematic of having a single place for
version attributes.
Having the ant build also use these properties for creating correctly
numbered jars is not part of the patch.
Note that I had to create a new file, src/clj/clojure/core_version.clj
, which is created by ant as a combination of template file
core_version-template.clj and the properties from version.properties.
You'll see that if you don't like the names of the keys in
version.properties, build.xml is the single place where to change them
(apart from version.properties, of course).
Also, if you don't like the name version.properties (e.g. if it should
be named project.properties or whatever for easing maven users), then
you just have to change its occurence in build.xml too.
If you like it,
Re: The Path to 1.0
Hi,
2009/4/28 Rich Hickey richhic...@gmail.com:
On Apr 27, 5:01 pm, Laurent PETIT laurent.pe...@gmail.com 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
in the names. It was suggested on IRC that perhaps it should also copy
the jar to their traditional (non-versioned) names, for greater
compatibility.
Why not ? The patch is really simple (3 lines), find it in attachment
and if you nevertheless want an issue in google code, I'll do it).
--
Laurent
Maven users please make sure that side of the build
works for you.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Index: build.xml
===
--- build.xml (révision 1358)
+++ build.xml (copie de travail)
@@ -46,6 +46,9 @@
filter token=clojure-version value=${clojure.version.label}/
/filterset
+ property name=clojure_noversion_jar location=clojure.jar/
+ property name=slim_noversion_jar location=clojure-slim.jar/
+ property name=src_noversion_jar location=clojure-sources.jar/
property name=clojure_jar location=clojure-${clojure.version.label}.jar/
property name=slim_jar location=clojure-slim-${clojure.version.label}.jar/
property name=src_jar location=clojure-sources-${clojure.version.label}.jar/
@@ -104,6 +107,7 @@
attribute name=Class-Path value=./
/manifest
/jar
+copy file=${clojure_jar} tofile=${clojure_noversion_jar} /
/target
target name=clojure-slim depends=compile-java
@@ -121,6 +125,7 @@
attribute name=Class-Path value=./
/manifest
/jar
+copy file=${slim_jar} tofile=${slim_noversion_jar} /
/target
target name=clojure-sources depends=init
@@ -129,6 +134,7 @@
fileset dir=${cljsrc}
includes=clojure/version.properties/
/jar
+copy file=${src_jar} tofile=${src_noversion_jar} /
/target
target name=jar depends=clojure/
Re: The Path to 1.0
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 builds and tests on all my code work fine. Konrad. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/28 Marko Kocić marko.ko...@gmail.com: 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 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/28 Laurent PETIT laurent.pe...@gmail.com: 2009/4/28 Marko Kocić marko.ko...@gmail.com: 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 clojure-contrib build tree removes the jars. I think it makes sense to do the same for clojure. -- Michael Wood esiot...@gmail.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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.properties, ant clean will not delete jars with old names and
it could be very confusing.
Rich, please find attached the patch (one line) for 1., if you agree
with Michael and with 1. option.
HTH,
--
Laurent
2009/4/28 Michael Wood esiot...@gmail.com:
2009/4/28 Laurent PETIT laurent.pe...@gmail.com:
2009/4/28 Marko Kocić marko.ko...@gmail.com:
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 clojure-contrib build tree removes the jars. I
think it makes sense to do the same for clojure.
--
Michael Wood esiot...@gmail.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Index: build.xml
===
--- build.xml (révision 1359)
+++ build.xml (copie de travail)
@@ -144,6 +144,11 @@
target name=clean
description=Remove autogenerated files and directories.
delete dir=${build}/
+delete
+ fileset dir=.
+include name=clojure*.jar/
+ /fileset
+/delete
delete file=pom.xml/
/target
Re: The Path to 1.0
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 current svn revision from the repository and publish a version named after the revision. Currently rev. 1359 is available in the kotka.de repo. For contrib is 724 available with the different modules as configurations. The patch is non-intrusive and adds build+ivy.xml as well as the ivy.xml. It's only a first stab and not perfect. Feedback welcome. Especially for unifying the version handling with the current maven implementation. I don't know maven and use Ivy for a few weeks now. So someone more experienced might want to comment? Sincerely Meikel clojure-ivy2.diff Description: Binary data contrib-ivy2.diff Description: Binary data smime.p7s Description: S/MIME cryptographic signature
Re: The Path to 1.0
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 awhile. Is this something you want to address before 1.0? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
New patch with corrections posted to google code,
regards,
--
laurent
2009/4/27 Laurent PETIT laurent.pe...@gmail.com:
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 generate
with filters from templates).
Then Rich asked if it was possible to not have to generate files. I
understand this question a little less broadly than not generate
files at all cost, but not generate files in the source code. So
that if the generation step is not followed by some tool for some
reason, things don't break - at compile time or run time -.
That's why I came up with this new version:
* a src/clj/clojure/version.properties file
* this version.properties file is the reference for version numbers.
It is on the classpath so it can be seen by clojure at runtime. It is
in a subdirectory of clojure-the-project so any tool can refer to it
relatively to the installation of clojure.
* I've added the needed code to clojure to load clojure version
number at startup time
I've also added function (clojure.core/clojure-version) that will
return a string representing the version from the structured
*clojure-version* map. The algorithm here is simple:
MAJOR.MINOR[.INCREMENT][-QUALIFIER][-SNAPSHOT]
* I've changed the ant build.xml so that it creates fully qualified
names with version attributes for the generated jars.
* Note on the :interim attribute: to protect the person who makes
releases from itself, instead of considering :interim to be true if
there is the true string in the properties file, I've made the
opposite choice: interim is true for any value other than false. So
if there is a typo in version.properties (e.g. tru instead of true),
then the release will be marked as interim, and that will not be a big
deal. In the other case, it would be a big deal if an official release
was made accidentally instead of an interim.
* finally, pom.xml file is now generated from ant as part of the
classic init step.
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.
HTH,
Feel free to use or not,
--
Laurent
2009/4/24 Howard Lewis Ship hls...@gmail.com:
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, 2009 at 8:24 AM, Laurent PETIT laurent.pe...@gmail.com
wrote:
2009/4/23 Rich Hickey richhic...@gmail.com:
On Apr 22, 12:41 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{: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 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* ?
Here a patch that allows to initialize from ant and from a file
version.properties the values in *clojure-version*.
The patch only addresses the problematic of having a single place for
version attributes.
Having the ant build also use these properties for creating correctly
numbered jars is not part of the patch.
Note that I had to create a new file, src/clj/clojure/core_version.clj
, which is created by ant as a combination of template file
core_version-template.clj and the properties from version.properties.
You'll see that if you don't like the names of the keys in
version.properties, build.xml is the single place where to change them
(apart from version.properties, of course).
Also, if you don't like the name version.properties (e.g. if it should
be named project.properties or whatever for easing maven users), then
you just have to change its occurence in build.xml too.
If you like it, it can file an issue to google code and attach the patch,
Thanks!
I can't say I love the idea of generating a file during build.
Me too, that's why I have made the file as short and independent as
possible.
Well, I tried to keep close to the idea of having the version numbers
built-in, similarly to what was commited where it was also not read
from a simpler file at load time.
What about clojure.jar containing a properties file it reads at load time?
Why not, indeed ? The file would have to placed in the classpath, e.g.
in directory
Re: The Path to 1.0
On 26 avr, 15:04, Rich Hickey richhic...@gmail.com wrote: On Apr 24, 1:57 pm, Howard Lewis Ship hls...@gmail.com 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 filters to accomplish both these goals. Sounds good, if by runtime file you mean a .properties file. Patch welcome. I can do it tonight. (It's already half done). Rich, I thought you wanted to avoid generating files in the source directories. So there are 2 options here: either the version number is in src/clj/ clojure/version.properties and every other script reads from there, either the version number is in build.xml and ant propagates it, even to the src/clj/clojure/version.properties location. I prefer the former to the latter, since then nothing is generated in the src/ folder. What is your preference ? If no answer, the patch I'll submit will be along the lines of the former. -- Laurent --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 26, 9:18 am, lpetit laurent.pe...@gmail.com wrote: On 26 avr, 15:04, Rich Hickey richhic...@gmail.com wrote: On Apr 24, 1:57 pm, Howard Lewis Ship hls...@gmail.com 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 filters to accomplish both these goals. Sounds good, if by runtime file you mean a .properties file. Patch welcome. I can do it tonight. (It's already half done). Rich, I thought you wanted to avoid generating files in the source directories. So there are 2 options here: either the version number is in src/clj/ clojure/version.properties and every other script reads from there, either the version number is in build.xml and ant propagates it, even to the src/clj/clojure/version.properties location. I prefer the former to the latter, since then nothing is generated in the src/ folder. What is your preference ? If no answer, the patch I'll submit will be along the lines of the former. The former is fine - thanks very much! Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 generate
with filters from templates).
Then Rich asked if it was possible to not have to generate files. I
understand this question a little less broadly than not generate
files at all cost, but not generate files in the source code. So
that if the generation step is not followed by some tool for some
reason, things don't break - at compile time or run time -.
That's why I came up with this new version:
* a src/clj/clojure/version.properties file
* this version.properties file is the reference for version numbers.
It is on the classpath so it can be seen by clojure at runtime. It is
in a subdirectory of clojure-the-project so any tool can refer to it
relatively to the installation of clojure.
* I've added the needed code to clojure to load clojure version
number at startup time
I've also added function (clojure.core/clojure-version) that will
return a string representing the version from the structured
*clojure-version* map. The algorithm here is simple:
MAJOR.MINOR[.INCREMENT][-QUALIFIER][-SNAPSHOT]
* I've changed the ant build.xml so that it creates fully qualified
names with version attributes for the generated jars.
* Note on the :interim attribute: to protect the person who makes
releases from itself, instead of considering :interim to be true if
there is the true string in the properties file, I've made the
opposite choice: interim is true for any value other than false. So
if there is a typo in version.properties (e.g. tru instead of true),
then the release will be marked as interim, and that will not be a big
deal. In the other case, it would be a big deal if an official release
was made accidentally instead of an interim.
* finally, pom.xml file is now generated from ant as part of the
classic init step.
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.
HTH,
Feel free to use or not,
--
Laurent
2009/4/24 Howard Lewis Ship hls...@gmail.com:
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, 2009 at 8:24 AM, Laurent PETIT laurent.pe...@gmail.com
wrote:
2009/4/23 Rich Hickey richhic...@gmail.com:
On Apr 22, 12:41 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{: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 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* ?
Here a patch that allows to initialize from ant and from a file
version.properties the values in *clojure-version*.
The patch only addresses the problematic of having a single place for
version attributes.
Having the ant build also use these properties for creating correctly
numbered jars is not part of the patch.
Note that I had to create a new file, src/clj/clojure/core_version.clj
, which is created by ant as a combination of template file
core_version-template.clj and the properties from version.properties.
You'll see that if you don't like the names of the keys in
version.properties, build.xml is the single place where to change them
(apart from version.properties, of course).
Also, if you don't like the name version.properties (e.g. if it should
be named project.properties or whatever for easing maven users), then
you just have to change its occurence in build.xml too.
If you like it, it can file an issue to google code and attach the patch,
Thanks!
I can't say I love the idea of generating a file during build.
Me too, that's why I have made the file as short and independent as possible.
Well, I tried to keep close to the idea of having the version numbers
built-in, similarly to what was commited where it was also not read
from a simpler file at load time.
What about clojure.jar containing a properties file it reads at load time?
Why not, indeed ? The file would have to placed in the classpath, e.g.
in directory src/jvm/clojure/lang or src/clj/clojure.
Could the same file be read by the various builds?
For ant, yes.
For maven2, it's more complex.
Indeed, I have read past the entire
Re: The Path to 1.0
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. While such incompatibilities are easy to fix (with an exclusion in refer- clojure), they are still a pain if they happen frequently. What about something like: (ns my-ns (:refer-clojure :version 1.0.0)) to prevent name clashes with future clojure vars? Christophe -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (en) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
Laurent PETIT a écrit :
2009/4/24 Christophe Grand christo...@cgrand.net:
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. While such
incompatibilities are easy to fix (with an exclusion in refer-
clojure), they are still a pain if they happen frequently.
What about something like:
(ns my-ns
(:refer-clojure :version 1.0.0))
to prevent name clashes with future clojure vars?
Do you think about something like that in the library part ? :
(defn #^{ :since 1.0.0} new-function [] )
I like that.
Adding #^{ :since :1.0.0} can prove tedious so I thought of some helper
functions such as: ns-unversioneds (returns a map), alter-since! and
emit-alter-since.
It would also be handy when one :use a library without a :only clause:
(ns my-ns
(:refer-clojure :version :1.0.0)
(:use clojure.contrib.seq-utils :version :1.1.0))
--
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (en)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/24 Christophe Grand christo...@cgrand.net:
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. While such
incompatibilities are easy to fix (with an exclusion in refer-
clojure), they are still a pain if they happen frequently.
What about something like:
(ns my-ns
(:refer-clojure :version 1.0.0))
to prevent name clashes with future clojure vars?
Do you think about something like that in the library part ? :
(defn #^{ :since 1.0.0} new-function [] )
I like that.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
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, 2009 at 8:24 AM, Laurent PETIT laurent.pe...@gmail.com wrote:
2009/4/23 Rich Hickey richhic...@gmail.com:
On Apr 22, 12:41 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{: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 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* ?
Here a patch that allows to initialize from ant and from a file
version.properties the values in *clojure-version*.
The patch only addresses the problematic of having a single place for
version attributes.
Having the ant build also use these properties for creating correctly
numbered jars is not part of the patch.
Note that I had to create a new file, src/clj/clojure/core_version.clj
, which is created by ant as a combination of template file
core_version-template.clj and the properties from version.properties.
You'll see that if you don't like the names of the keys in
version.properties, build.xml is the single place where to change them
(apart from version.properties, of course).
Also, if you don't like the name version.properties (e.g. if it should
be named project.properties or whatever for easing maven users), then
you just have to change its occurence in build.xml too.
If you like it, it can file an issue to google code and attach the patch,
Thanks!
I can't say I love the idea of generating a file during build.
Me too, that's why I have made the file as short and independent as possible.
Well, I tried to keep close to the idea of having the version numbers
built-in, similarly to what was commited where it was also not read
from a simpler file at load time.
What about clojure.jar containing a properties file it reads at load time?
Why not, indeed ? The file would have to placed in the classpath, e.g.
in directory src/jvm/clojure/lang or src/clj/clojure.
Could the same file be read by the various builds?
For ant, yes.
For maven2, it's more complex.
Indeed, I have read past the entire reference of the pom, searched
through the ml, and it seems that it's not possible at all to have
maven2 read properties file but its own which are not suitable for our
purpose.
So I that even if we don't generate a clojure source file by reading
version.properties at load time from the classpath, it will be
difficult to avoid having to generate the maven2 pom.xml file from a
pom-template.xml ...
Not that it would be difficult, it's just a matter of adding a
init-mvn task in the ant build.xml, and make all mvn related ant tasks
depend on it.
Concerning what Howard suggested, having the maven2 pom.xml file be
the reference where the version information is placed, I can't say I
like this idea very much.
That's because maven2 pom.xml is not as structured as you have
structured the current version information (maven2 just has a single
version element where you place whatever you want, it's not
decomposed into major, minor, ... so it will be more difficult to do
the pattern matching :-).
And also, maven2 pom.xml is not the master build file, it's ant, so it
sounds weird to have ant go parse maven2.xml file to extract the
versioning information.
My 0,02€,
--
Laurent
--
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/23 Rich Hickey richhic...@gmail.com:
On Apr 22, 12:41 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{: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 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* ?
Here a patch that allows to initialize from ant and from a file
version.properties the values in *clojure-version*.
The patch only addresses the problematic of having a single place for
version attributes.
Having the ant build also use these properties for creating correctly
numbered jars is not part of the patch.
Note that I had to create a new file, src/clj/clojure/core_version.clj
, which is created by ant as a combination of template file
core_version-template.clj and the properties from version.properties.
You'll see that if you don't like the names of the keys in
version.properties, build.xml is the single place where to change them
(apart from version.properties, of course).
Also, if you don't like the name version.properties (e.g. if it should
be named project.properties or whatever for easing maven users), then
you just have to change its occurence in build.xml too.
If you like it, it can file an issue to google code and attach the patch,
Thanks!
I can't say I love the idea of generating a file during build.
Me too, that's why I have made the file as short and independent as possible.
Well, I tried to keep close to the idea of having the version numbers
built-in, similarly to what was commited where it was also not read
from a simpler file at load time.
What about clojure.jar containing a properties file it reads at load time?
Why not, indeed ? The file would have to placed in the classpath, e.g.
in directory src/jvm/clojure/lang or src/clj/clojure.
Could the same file be read by the various builds?
For ant, yes.
For maven2, it's more complex.
Indeed, I have read past the entire reference of the pom, searched
through the ml, and it seems that it's not possible at all to have
maven2 read properties file but its own which are not suitable for our
purpose.
So I that even if we don't generate a clojure source file by reading
version.properties at load time from the classpath, it will be
difficult to avoid having to generate the maven2 pom.xml file from a
pom-template.xml ...
Not that it would be difficult, it's just a matter of adding a
init-mvn task in the ant build.xml, and make all mvn related ant tasks
depend on it.
Concerning what Howard suggested, having the maven2 pom.xml file be
the reference where the version information is placed, I can't say I
like this idea very much.
That's because maven2 pom.xml is not as structured as you have
structured the current version information (maven2 just has a single
version element where you place whatever you want, it's not
decomposed into major, minor, ... so it will be more difficult to do
the pattern matching :-).
And also, maven2 pom.xml is not the master build file, it's ant, so it
sounds weird to have ant go parse maven2.xml file to extract the
versioning information.
My 0,02€,
--
Laurent
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 21, 12:18 pm, Daniel Jomphe danieljom...@gmail.com 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
major.minor.incremental-qualifier as documented here:
http://www.sonatype.com/books/maven-book/reference/pom-relationships-...
Thanks for the info.
So I was wrong in two ways:
1. There's in fact a convention for version strings: M.m.i-qualifier
2. The string SNAPSHOT may appear anywhere inside the version
string.
Keeping SNAPSHOT at the end and adding a rc1 qualifier, to
illustrate:
version: 1.0.0-rc1-SNAPSHOT
yields: clojure-1.0.0-rc1-snapshot.jar
(and ...-slim.jar, ...-sources.jar)
I've added *clojure-version* in SVN 1354. According to the above it's
still not quite right. I'm thinking now the runtime view should be
something like:
{: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.
A possible doc string:
(doc *clojure-version*)
The version info for Clojure core, as a map
containing :major :minor :incremental, and (optional) :qualifier
and :interim keys. Feature releases may increment :minor and/
or :major, bugfix releases will increment :incremental. Possible
values of :qualifier include :rc, :beta etc,
and :interim will be true for non-release builds.
I'm still left with a few questions and would appreciate some help.
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 are needed to the build scripts to produce version-
numbered jars?
Thanks,
Rich
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
Hi,
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{: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 give it the same meaning as what was suggested previously in the
thread).
The qualifier is there to be able to produce several different outputs
(e.g. jars in our case) from the same version number.
A version is fully qualified with :major + :minor + :incremental + :interim
An output made from the version is fully qualified with :major +
:minor + :incremental + :interim + :qualifier.
If we look at what are the different outputs currently are for
clojure, :qualifier can have 3 values:
(empty string) : for producing clojure-M.m.i.jar
slim : for producting clojure-M.m.i-slim.jar
sources : for producing clojure-M.m.i-sources.jar
:qualifier will be needed in projects which depend upon clojure, to
fully qualify which jar among the 3 possibilities one want to depend
upon.
Regards,
--
Laurent
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
OOooops sorry, I mistook qualifier for classifier,
:qualifier seems totally appropriate here, sorry for the noise,
--
Laurent
2009/4/22 Laurent PETIT laurent.pe...@gmail.com:
Hi,
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{: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 give it the same meaning as what was suggested previously in the
thread).
The qualifier is there to be able to produce several different outputs
(e.g. jars in our case) from the same version number.
A version is fully qualified with :major + :minor + :incremental + :interim
An output made from the version is fully qualified with :major +
:minor + :incremental + :interim + :qualifier.
If we look at what are the different outputs currently are for
clojure, :qualifier can have 3 values:
(empty string) : for producing clojure-M.m.i.jar
slim : for producting clojure-M.m.i-slim.jar
sources : for producing clojure-M.m.i-sources.jar
:qualifier will be needed in projects which depend upon clojure, to
fully qualify which jar among the 3 possibilities one want to depend
upon.
Regards,
--
Laurent
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
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 *clojure-version* ? What changes are needed to the build scripts to produce version- numbered jars? Since Java is so much geared towards properties files, I suppose a version.properties file would ease integration with each build tool. *Ant* could easily fetch what it needs from the props file. Not sure how one does it though. *Maven*: if I remember well from my experience, the version of the maven artifact couldn't be populated dynamically. If it could, the props file would be one of the closest things to help make it work. *Clojure runtime* could easily populate its *clojure-version* on startup from the props file. That said, if the dynamic fetching from a props file approach isn't workable, an easier approach would be filling a few holes on pre-build time, using a script that calls to a template engine like StringTemplate, to inject the version as needed, where needed. Of course, this sounds ugly, especially considering it would be alien to automated tools like IDEs and etc. Let's hope someone knows better than I do. BTW, the most common approach I've seen to this problem is capitulate; let's just manually hard-code the version in the three places; anyways, we won't have to change it often. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{: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 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* ?
Here a patch that allows to initialize from ant and from a file
version.properties the values in *clojure-version*.
The patch only addresses the problematic of having a single place for
version attributes.
Having the ant build also use these properties for creating correctly
numbered jars is not part of the patch.
Note that I had to create a new file, src/clj/clojure/core_version.clj
, which is created by ant as a combination of template file
core_version-template.clj and the properties from version.properties.
You'll see that if you don't like the names of the keys in
version.properties, build.xml is the single place where to change them
(apart from version.properties, of course).
Also, if you don't like the name version.properties (e.g. if it should
be named project.properties or whatever for easing maven users), then
you just have to change its occurence in build.xml too.
If you like it, it can file an issue to google code and attach the patch,
Regards,
--
Laurent
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Index: version.properties
===
--- version.properties (révision 0)
+++ version.properties (révision 0)
@@ -0,0 +1,5 @@
+clojure.version.major=1
+clojure.version.minor=0
+clojure.version.incremental=0
+clojure.version.qualifier=RC1
+clojure.version.interim=false
Index: src/clj/clojure/core.clj
===
--- src/clj/clojure/core.clj (révision 1354)
+++ src/clj/clojure/core.clj (copie de travail)
@@ -10,7 +10,6 @@
(def unquote)
(def unquote-splicing)
-(def *clojure-version* {:major 1 :minor 0 :incremental 0 :qualifier RC1})
(def
#^{:arglists '([ items])
@@ -3954,11 +3953,6 @@
(defmacro add-doc {:private true} [name docstring]
`(alter-meta! (var ~name) assoc :doc ~docstring))
-(add-doc *clojure-version*
- The version info for Clojure core, as a map containing :major :minor :incremental and :qualifier keys.
- Feature releases may increment :minor and/or :major, bugfix releases will increment :incremental.
- Possible values of :qualifier include \GA\, \SNAPSHOT\, \RC-x\ \BETA-x\)
-
(add-doc *file*
The path of the file being evaluated, as a String.
@@ -4037,8 +4031,8 @@
(load core_proxy)
(load core_print)
(load genclass)
+(load core_version)
-
;;; futures (needs proxy);;
(defn future-call
Takes a function of no args and yields a future object that will
@@ -4106,3 +4100,4 @@
`(letfn* ~(vec (interleave (map first fnspecs)
(map #(cons `fn %) fnspecs)))
~...@body))
+
Index: core_version-template.clj
===
--- core_version-template.clj (révision 0)
+++ core_version-template.clj (révision 0)
@@ -0,0 +1,18 @@
+; Copyright (c) Laurent Petit. All rights reserved.
+; The use and distribution terms for this software are covered by the
+; Eclipse Public License 1.0 (http://opensource.org/licenses/eclipse-1.0.php)
+; which can be found in the file epl-v10.html at the root of this distribution.
+; By using this software in any fashion, you are agreeing to be bound by
+; the terms of this license.
+; You must not remove this notice, or any other, from this software.
+
+(in-ns 'clojure.core)
+
+(let [clojure-version {:major 'CLOJURE_VERSION_MAJOR
+ :minor 'CLOJURE_VERSION_MINOR
+ :incremental 'CLOJURE_VERSION_INCREMENTAL
+ :qualifier 'CLOJURE_VERSION_QUALIFIER}]
+ (def *clojure-version*
+(if* 'CLOJURE_VERSION_INTERIM
+ (. clojure.lang.RT (assoc clojure-version :interim true))
+ clojure-version)))
Index: build.xml
===
--- build.xml (révision 1354)
+++ build.xml (copie de travail)
@@ -16,13 +16,17 @@
property name=slim_jar location=clojure-slim.jar/
property name=src_jar location=clojure-sources.jar/
property
Re: The Path to 1.0
On Apr 21, 1:52 am, Rich Hickey richhic...@gmail.com 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/21 AndrewC. mr.bl...@gmail.com: On Apr 21, 1:52 am, Rich Hickey richhic...@gmail.com 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 This book is not up to date and does not cover the classifier. This one half page paragraph from the maven POM reference is more up to date: http://maven.apache.org/pom.html#Maven_Coordinates HTH, -- Laurent --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 another subject, which is more related to build management. 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 think so, but I ask to be certain of that) I believe the correct approach would indeed have slim as a classifier, because slim is an hybrid of the default classifier (.java files as bytecode only) and of the source classifier (.clj files). That fits in the original definition of classifier: The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. Thus, due to clojure's way of bundling AOT-compiled bytecode and/or clojure data structures as code, I believe it makes sense to introduce a new conventional classifier which is alien to purely java-based projects but makes sense to clojure projects. Following this, a conventional maven packaging of clojure would yield the following: clojure-1.0.0-snapshot.jar clojure-1.0.0-snapshot-slim.jar clojure-1.0.0-snapshot-javadoc.jar clojure-1.0.0-snapshot-sources.jar Now, let's suppose we really don't care about the javadoc-only packaging. Upon official release: clojure-1.0.0.jar clojure-1.0.0-slim.jar clojure-1.0.0-sources.jar clojure-1.0.1-snapshot.jar clojure-1.0.1-snapshot-slim.jar clojure-1.0.1-snapshot-sources.jar clojure-1.1.0-snapshot.jar clojure-1.1.0-snapshot-slim.jar clojure-1.1.0-snapshot-sources.jar Howard has already done this for the snapshot of 1.0.0, but he versioned it 1.0: http://tapestry.formos.com/maven-snapshot-repository/org/clojure/clojure-lang/1.0-SNAPSHOT/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Mon, Apr 20, 2009 at 8:52 PM, Rich Hickey richhic...@gmail.com 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 1)
then
{ :major 1 :minor 0 :release 0 :status :RC2 } (release candidate 2)
etc.
and finally
{ :major 1 :minor 0 :release 0 :status :GA1 } (Global Availibility 1)
I'm unfamiliar with the POM version coordinate system - any hints?
Rich
Others have commented on the whole groupId, artifactId, etc., etc. But in
terms of the parts of the version number, they are named
major.minor.incremental-qualifier as documented here:
http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html
Paul
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
On Sat, Apr 18, 2009 at 5:34 AM, Isak Hansen isak.han...@gmail.com wrote: On Thu, Apr 16, 2009 at 6:53 PM, Rich Hickey richhic...@gmail.com 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 from contrib to the standard library? - Make ClojureCLR and clojurescipt separate projects with their own branches and so on. 3. I'd like to see the clojure source hooked up to some CI system, along the lines of http://ci.rubyonrails.org/. I've already done this; its on http://tapestry.formos.com/ I know it's not a vote, but I use git as well. 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 major.minor.incremental-qualifier as documented here: http://www.sonatype.com/books/maven-book/reference/pom-relationships-... Thanks for the info. So I was wrong in two ways: 1. There's in fact a convention for version strings: M.m.i-qualifier 2. The string SNAPSHOT may appear anywhere inside the version string. Keeping SNAPSHOT at the end and adding a rc1 qualifier, to illustrate: version: 1.0.0-rc1-SNAPSHOT yields: clojure-1.0.0-rc1-snapshot.jar (and ...-slim.jar, ...-sources.jar) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
Laurent PETIT wrote:
version: 1.0.0-rc1-SNAPSHOT
yields: clojure-1.0.0-rc1-snapshot.jar
(and ...-slim.jar, ...-sources.jar)
There it is. But why having snapshot in the name of the jar,
shouldn't it just be SNAPSHOT (as far as I remember) ?
That is:
{ :major 1 :minor 0 :incremental 0-rc1-SNAPSHOT }
gives version: 1.0.0-rc1-SNAPSHOT
yields: clojure-1.0.0-rc1-SNAPSHOT.jar
(and ...-slim.jar, ...-sources.jar)
The snapshot was a shortened version of the reality, for example:
20090222.174152-1
So in reality, snapshot packages look like:
clojure-1.0.0-rc1-20090222.174152-1.jar
Even though, when we add clojure as a dependency of some project, we
will ask for the version 1.0.0-rc1-SNAPSHOT.
See
http://tapestry.formos.com/maven-snapshot-repository/org/clojure/clojure-lang/1.0-SNAPSHOT/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/21 Daniel Jomphe danieljom...@gmail.com:
Laurent PETIT wrote:
version: 1.0.0-rc1-SNAPSHOT
yields: clojure-1.0.0-rc1-snapshot.jar
(and ...-slim.jar, ...-sources.jar)
There it is. But why having snapshot in the name of the jar,
shouldn't it just be SNAPSHOT (as far as I remember) ?
That is:
{ :major 1 :minor 0 :incremental 0-rc1-SNAPSHOT }
gives version: 1.0.0-rc1-SNAPSHOT
yields: clojure-1.0.0-rc1-SNAPSHOT.jar
(and ...-slim.jar, ...-sources.jar)
The snapshot was a shortened version of the reality, for example:
20090222.174152-1
So in reality, snapshot packages look like:
clojure-1.0.0-rc1-20090222.174152-1.jar
Even though, when we add clojure as a dependency of some project, we
will ask for the version 1.0.0-rc1-SNAPSHOT.
See
http://tapestry.formos.com/maven-snapshot-repository/org/clojure/clojure-lang/1.0-SNAPSHOT/
Thanks, seems like I had memories wrong,
--
Laurent
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
Stuart Sierra the.stuart.sie...@gmail.com writes:
On Apr 20, 1:48 pm, Rich Hickey richhic...@gmail.com 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.
The term I've often seen is :bugfix for the least-significant version segment.
-Phil
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/20 Stuart Sierra the.stuart.sie...@gmail.com
On Apr 20, 1:48 pm, Rich Hickey richhic...@gmail.com 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.
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 segment indicates a particular build).
(http://wiki.eclipse.org/Version_Numbering#Guidelines_on_versioning_plug-ins)
--
Laurent Petit
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/20 Rich Hickey richhic...@gmail.com:
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 :interim for non?
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 the -SNAPSHOT keyword.
So every build that does not remove this -SNAPSHOT suffix can not be
mistaken with the real release.
Note that such tools are not as structured as you suggest and just
reserve a single field for version numbering.
I think it is a good idea to add this :status attribute. It could be
used to mark progression towards a fully featured version, as well :
{ :major 1 :minor 0 :release 0 :status :SNAPSHOT }
then
{ :major 1 :minor 0 :release 0 :status :RC1 } (release candidate 1)
then
{ :major 1 :minor 0 :release 0 :status :RC2 } (release candidate 2)
etc.
and finally
{ :major 1 :minor 0 :release 0 :status :GA1 } (Global Availibility 1)
One thing to be considered, also, would be a :qualifier attribute that
could say : this is the version packaged with sources, this is the
slim version, ...).
HTH,
--
Laurent
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
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 the -SNAPSHOT keyword.
So every build that does not remove this -SNAPSHOT suffix can not be
mistaken with the real release.
Note that such tools are not as structured as you suggest and just
reserve a single field for version numbering.
I think it is a good idea to add this :status attribute. It could be
used to mark progression towards a fully featured version, as well :
{ :major 1 :minor 0 :release 0 :status :SNAPSHOT }
then
{ :major 1 :minor 0 :release 0 :status :RC1 } (release candidate 1)
then
{ :major 1 :minor 0 :release 0 :status :RC2 } (release candidate 2)
etc.
and finally
{ :major 1 :minor 0 :release 0 :status :GA1 } (Global Availibility 1)
Given the likelihood that pom's will be used by some people, with
maven or ivy, it would be good to have some scheme that maps to and
from the pom version coordinate system in a transparent fashion,
particularly in relation to this particular feature of that system.
Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Always have a vision. Why spend your life making other people’s dreams?
-- Orson Welles (1915-1985)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
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 segment indicates a particular build). And let's not forget _feu_ Sun's terminology: update, as in Java 6 update 14, which really means 1.6.14. :) Now, personally, what sounds the best in my ears is revision. There's of course yet more possibilities: http://en.wikipedia.org/wiki/Software_versioning --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 in code where you maintain
the version number by appending the -SNAPSHOT keyword.
So every build that does not remove this -SNAPSHOT suffix can not be
mistaken with the real release.
Note that such tools are not as structured as you suggest and just
reserve a single field for version numbering.
I think it is a good idea to add this :status attribute. It could be
used to mark progression towards a fully featured version, as well :
{ :major 1 :minor 0 :release 0 :status :SNAPSHOT }
then
{ :major 1 :minor 0 :release 0 :status :RC1 } (release candidate 1)
then
{ :major 1 :minor 0 :release 0 :status :RC2 } (release candidate 2)
etc.
and finally
{ :major 1 :minor 0 :release 0 :status :GA1 } (Global Availibility 1)
Given the likelihood that pom's will be used by some people, with
maven or ivy, it would be good to have some scheme that maps to and
from the pom version coordinate system in a transparent fashion,
particularly in relation to this particular feature of that system.
I'm unfamiliar with the POM version coordinate system - any hints?
Rich
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: The Path to 1.0
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 groupId:artifactId:packaging:version to identify a particular artifact e.g. library. GroupId + Artifact Id is a qualified name - think java package name. Packaging specifies how the artifact is packaged e.g. jar or war, but it doesn't contribute the id of the project. Version numbers are as you expect, but can be suffixed with '- SNAPSHOT', which effectively creates a distinct subspace of versions ordered by creation date. By depending on a 'a.b.c-SNAPSHOT' version, you get the latest (by date) artifact marked with 'a.b.c-SNAPSHOT'. When you release the artifact you remove the '-SNAPSHOT'. In effect the suffix creates two different versioning spaces, one of which is strictly determined by the hierarchic numeric ordering, and another that allows duplicates ordered by date within a specific hierarchically ordered version. AFAIK, an 'a.b.c-SNAPSHOT' version will not satisfy a request for 'a.b.c' e.g. -SNAPSHOT is not a further qualifier. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead. -- Ron Avitzur --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 concept of a coordinate, which is groupId:artifactId:packaging:version to identify a particular artifact e.g. library. GroupId + Artifact Id is a qualified name - think java package name. Packaging specifies how the artifact is packaged e.g. jar or war, but it doesn't contribute the id of the project. Version numbers are as you expect, but can be suffixed with '-SNAPSHOT', which effectively creates a distinct subspace of versions ordered by creation date. By depending on a 'a.b.c-SNAPSHOT' version, you get the latest (by date) artifact marked with 'a.b.c-SNAPSHOT'. When you release the artifact you remove the '-SNAPSHOT'. In effect the suffix creates two different versioning spaces, one of which is strictly determined by the hierarchic numeric ordering, and another that allows duplicates ordered by date within a specific hierarchically ordered version. AFAIK, an 'a.b.c-SNAPSHOT' version will not satisfy a request for 'a.b.c' e.g. -SNAPSHOT is not a further qualifier. This BTW presumes a fairly simplistic dependency selection mechanism. In a previous life I did a lot of work with dependency algebras, and a far more powerful solution for managing configuration is to allow artifacts to be annotated with multidimensional versioning attributes organized by feature, using an ordered unification based configuration resolution mechanism. Somewhat like versioned requires/provides but with richer semantics. My experience was such systems are too complicated for mass deployment, and their use needs to be motivated by a significant configuration management requirement, which is why I suggest sticking to the far simpler maven/ivy POM model. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 All that is required for evil to triumph is that good men do nothing. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 to release version whatever, and this is our most recent snapshot of its edge development. But that's not all that has been mentioned in this thread re: maven conventions. A release is uniquely identified by a few attributes: groupId:artifactId:packaging:classifier:version The classifier part has alson been mentioned. From maven's doc: --- The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use. Another common use case for classifiers is the need to attach secondary artifacts to the project's main artifact. If you browse the Maven central repository, you will notice that the classifiers sources and javadoc are used to deploy the project source code and API docs along with the packaged class files. --- Lots of java libraries are distributed thusly: (1) org.clojure:clojure:jar:1.0.0 (no classifier) (2) org.clojure:clojure:jar:javadoc:1.0.0 (3) org.clojure:clojure:jar:sources:1.0.0 So 1 is bytecode release; 2 is only javadoc; 3 is full sources w/o bytecode. Of course, javadoc is also included in the sources release (3). Hope this answered your question, and more, if needed. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 richhic...@gmail.com wrote: 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 think so, but I ask to be certain of that) Thanks, -- Laurent 2009/4/21 Daniel Jomphe danieljom...@gmail.com: 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 to release version whatever, and this is our most recent snapshot of its edge development. But that's not all that has been mentioned in this thread re: maven conventions. A release is uniquely identified by a few attributes: groupId:artifactId:packaging:classifier:version The classifier part has alson been mentioned. From maven's doc: --- The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use. Another common use case for classifiers is the need to attach secondary artifacts to the project's main artifact. If you browse the Maven central repository, you will notice that the classifiers sources and javadoc are used to deploy the project source code and API docs along with the packaged class files. --- Lots of java libraries are distributed thusly: (1) org.clojure:clojure:jar:1.0.0 (no classifier) (2) org.clojure:clojure:jar:javadoc:1.0.0 (3) org.clojure:clojure:jar:sources:1.0.0 So 1 is bytecode release; 2 is only javadoc; 3 is full sources w/o bytecode. Of course, javadoc is also included in the sources release (3). Hope this answered your question, and more, if needed. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 17, 2:47 pm, revoltingdevelopment christopher.jay.jo...@gmail.com 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 raised so far. I would second that and add that having a fixed version (be it .99, ot 1.0 or 1.1 or whatever) is not useful only for the book, but also for tooling. It'd be nice to have IDE plugins versions, or Waterfront versions, that depend on a fixed stable version instead of the latest snapshot which my break or change stuff from one release to the next. Of course, once there is that first stable version with which the tool works, there's no harm in having alpha or beta release of the tool version using the latest Clojure snapshot. Plus it's always nice to be able to develop a library or whatever and assigning a language version to it, like we do with Java or .Net. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 17, 2:47 pm, revoltingdevelopment christopher.jay.jo...@gmail.com 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 raised so far. I would second that and add that having a fixed version (be it .99, or 1.0 or 1.1 or whatever) is not useful only for the book, but also for tooling. It'd be nice to have IDE plugins versions, or Waterfront versions, that depend on a fixed stable version instead of the latest snapshot which my break or change stuff from one release to the next. Of course, once there is that first stable version with which the tool works, there's no harm in having alpha or beta release of the tool version using the latest Clojure snapshot. Plus it's always nice to be able to develop a library or whatever and assigning a language version to it, like we do with Java or .Net. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 having an easy way to start using Clojure like that would definitely help newcomers. Many languages ship with modes for different editors as well; it might be nice to include the more basic modes (i.e. not SLIME and Gorilla, but clojure-mode and a syntax file for vim) Finally, I think emulating Perl's strong commitment to unit testing the language would be a beneficial thing in the long run. Cheers, Vince On Apr 16, 12:53 pm, 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. - 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? 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 has already reached 1.0 maturity in my eyes because: 1) There are large projects already using it - Luc/Stuart have already done major deployments - I'm quite amazed at the depth of the projects you get a peek of from the group - Heck Itay wrote a full clj IDE in 2 months which was really slick 2) My own experience - I used to have to svn update regularly and check the group to code in clj, for the last 2 months I've noticed no need for that anymore - Bug reports seem to have dried up, and I don't encounter any ever (I encounter my own bugs regularly still!) - No radical diversions to core being discussed 3) Core language considerations - All 1.0 discussion has been infrastructure related; indicates people are comfortable with how the language itself looks - Type systems is the only lively debate I've noticed on the group in this area, and I don't see it holding 1.0 back - http://code.google.com/p/clojure/issues/list is quite boring these days :P 4) JVM safety net - I don't think anyone can claim I can't do X in Clojure Many important items and insightful observations have been discussed in this thread which I totally agree need to be pursued with due vigor. To my mind however Clojure is ready and the most important priority is to hand out the party poppers and novelty hats. Well done Rich and core contributors, I hope you choose to stamp 1.0 sooner than later [obviously when you feel comfortable with that] :) Regards, Tim. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 konrad.hin...@laposte.netwrote: 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 the kernel can develop somewhat independently of the applications that target it. True, but there is still a standard set of packages (or rather functionalities) that all but the most specialized Linux distributions contain and that everybody expects to find in a normal Linux distribution. Things like the shell, ls, rm, etc. One way to compensate for a lack of batteries included might be a powerful, agnostic library management solution, which allows for different contrib libraries, VMs, or architectures, but that definitely seems like a 2.0 feature. That sounds like a lot of work, and it won't take care of one important contribution of a standard library: standardization for basic, well-understood tasks. It's no fun to program in an environment where there are three competing libraries for parsing HTML that differ only in function names and parameter order. Konrad. -- John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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) 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 the kernel can develop somewhat independently of the applications that target it. Eventually, clojure-contrib will be much much larger than clojure the language. If clojure-contrib is Clojure's standard, most of the work involved in developing Clojure 2.0 won't be in core but in hammering on contrib. If that's what people want then great. It just seems like a less flexible solution to me. One way to compensate for a lack of batteries included might be a powerful, agnostic library management solution, which allows for different contrib libraries, VMs, or architectures, but that definitely seems like a 2.0 feature. On Sat, Apr 18, 2009 at 1:51 AM, Tom Faulhaber tomfaulha...@gmail.comwrote: 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 version number (e.g. 1.0.0) and the subversion number (e.g. r1352) in the built clojure.jar somewhere that's easily accessible to tools that are trying to do library management. My solution to this would probably just be to generate a couple of (def *clojure-version- number* 1.0.0) things as part of the build. Do any Java/Maven heads have more sophisticated ideas that we should consider here? I've just started hacking on some svn manipulation stuff (and a little bit of jar manipulation) in the process of doing my contrib autodoc robot, so I'd be happy to help here too. 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 need to address that. (To my mind, the python library has always felt very ad hoc.) I do not agree with John Newman that the Java standard library should be the Clojure standard library. There's enough that's different in Clojure that I think we do want some of our own ways to approach things. I think there's also space for some great documents ( screencasts, etc.) that show how to leverage parts of the Java library to do cool things in Clojure. (Rich's demo of building swing apps in Clojure comes to mind.) I'd also like to see a little more focus on the perl/python/ruby equivalence from a newbie perspective. That is, more clarity around startup, script execution (including having an equivalent to python's if __name__ == '__main__': construct), class path management, etc. I know that this is one area where being in the JVM ecosystem makes our life worse rather than better, but approaching Clojure is still a bit daunting compared to these other languages. You can count me among the git fanboys, but I can't get too worked up about moving off google code right now (and that would be necessary if we switched to git). (Aside to Matt Revelle: You can use git-svn on the client side (and I do) but that provides only a local solution, so it isn't a magic bullet.) Really, we all know that 1.0 means 1.0. Clojure will be much further along than most other languages at their 1.0 point, so I wouldn't stress over it too much. I think that might have been 6 cents worth :-). Tom -- John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Thu, Apr 16, 2009 at 6:53 PM, Rich Hickey richhic...@gmail.com 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 from contrib to the standard library? - Make ClojureCLR and clojurescipt separate projects with their own branches and so on. 3. I'd like to see the clojure source hooked up to some CI system, along the lines of http://ci.rubyonrails.org/. I know it's not a vote, but I use git as well. Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 kinds of nonsense internal wars in the community ) We seem to be unanimous in preferring git. Not at all. I am a convinced Mercurial user, for example, and I don't even have git installed on my machine (I do have svn). However, I didn't participate in this debate because I think it is pointless. VCS issues are as much a matter of personal preference as technical merit. It's Rich who does all of the commits, so it's for him to choose. That's not the case for contrib. If Rich is the only committer *and contributor* to core, then it's a moot point what VCS is used for core. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 A Buddhist walks up to a hot-dog stand and says, Make me one with everything. He then pays the vendor and asks for change. The vendor says, Change comes from within. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 18, 3:15 am, John Newman john...@gmail.com 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 that the current contrib is not well- defined and probably not the best long-term solution. I don't think that it was meant to be. Most of us seem to agree that, while this is important, it shouldn't stop us for going to 1.0. At the same time, we should continue working this issue as a community. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On 16.04.2009, at 18:53, Rich Hickey wrote: What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? What I tacitly expect from a 1.0 release (or any official, numbered release) is - bug fixes without imposed changes in functionality for at least a year - the promise not to introduce breaking changes in future releases unless there is a very good reason to do so - a clear indication of potentially breaking changes by a change in version number - an outline of how future changes will be handled so that I can prepare for them in my own code management For a 1.0 release in particular, I expect sufficient stability and completeness for use in real-life projects. From my own experience with today's Clojure, I'd say the stability is there. I am less convinced about completeness, but that's mainly because there are many things I haven't yet tried to do. Overall, the discussions on the group don't leave the impression that there are glaring holes anywhere. However, it is possible that many users are relying on clojure-contrib for completeness, and if that is the case, the status of clojure-contrib needs to be considered as well before a 1.0 release. 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. While such incompatibilities are easy to fix (with an exclusion in refer- clojure), they are still a pain if they happen frequently. Another point is multimethod dispatch. Various ideas have been discussed here, and most of them, if adopted, are likely to break a lot of code relying on the current approach. As for bug fixes for a stable release, you pointed out that someone would have to take care of them (mostly by backporting fixes in trunk I guess). I don't think it will be hard to find a team of volunteers, but it would be nice to arrange this before an official release. The same team could also maintain a stable subset of clojure-contrib as a kind of standard library. Konrad. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
What I'd really like to see are better command line tools. Make it easy to compile, merge with java code, (or jython, or jruby, etc), and a repl that came closer to something like IPython. A prototype lint would be nice too, assuming it's possible for a lisp. And of course, easier install. The library stuff sounds good too. Just off the top of my head. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/16 Rich Hickey richhic...@gmail.com: 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 of VCS and B) the state of clojure-contrib. Here's my thoughts on both: A) VCS Python has just changed from Subversion to Hg (there is a great PEP article that details reasons for doing so here: http://www.python.org/dev/peps/pep-0374/). They did this because they had a need to and at the moment Clojure doesn't have this need (because there is only one person doing commits!). While it seems pointless changing technology for the sake of it, I also think - if it's an inevitable change in the future - why not just do it now? Rich - is changing VCS something you would consider at this stage? B) clojure-contrib For me, the purpose of clojure-contrib is a little confusing. Is it the Clojure standard library? well a lot of standard libraries are not in clojure-contrib so I think the answer is no. Is it a special holder repos for code that might someday be moved up into the core language? Well, that's what I thought it was for but there is currently stuff in there that will never be in the core language IMO. I think we need to decide what clojure-contrib is before a 1.0 release (or maybe it's already very clear and I have just missed something!). In general, I think there should be only two things - the core language and a set of libraries. Whether the libraries are managed CPAN-style or whether they are delivered as part of a standard library (like with Python) I don't know at this point - but having a special third place for libraries that may or may not go into core seems unnecessary to me. Paul. -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne Wear, DH5 8NE. This message is intended only for the use of the person(s) (the intended recipient(s)) to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 it is very important that Stuart's book correspond to a release of Clojure. It would be huge for newcomers coming to Clojure find a book that says Covers Clojure 1.0, and a compatible download for 1.0.x with the latest fixes. Stuart has worked hard on tracking the latest changes, as have I in trying to get in those changes that would be breaking as soon as I could before 1.0. I'm presuming it's not too late to get Covers Clojure 1.0 in there (Stuart?), and, if so, it is a factor in this decision. I'll also add that there is plenty more I'd like to do, and as soon as I get into that trunk will again be changing rapidly. There simply has to be a branch for fixes only. As to the feedback: 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. Advantages of Maven vs Ivy vs whatever should be separate. 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 in the language itself. A deprecation policy is a good idea. Backward compatibility mode is unlikely. 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. 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. Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 use a decimal point? call it 1|0, and then you can REALLY have your own definition as to what the version meant. Seriously, I agree that there would be power in having a book that corresponds with 1.0 even to the extent that it were part of a title, like Clojure 1.0. * Ok, here's another perspective now:* People talk about Erlang as being fairly unique in that distributed computing was taken into consideration as part of the core language design rather than being bootstrapped on top as an after thought. Clojure has a lot of nice design considerations along these lines, too. If the 1.0 line is drawn in the sand, and there are a lot of nice design ideas coming around the corner, while baselining now (after moving a few things from the core like file io) could make things feel more sane, if any of these changes really are revolutionary, they might not have the same pizaz in a post 1.0 release. They could with the right marketting, like redesigned from the ground up, or something, but it could be somewhat like Perl 6.0. I hear it's nice and maybe taking a look at, but when it first, finally came out, the message I got (mostly from Perl people) was don't bother. That could happen with a 2.0 or post 1.0, too. On Fri, Apr 17, 2009 at 6:21 AM, Rich Hickey richhic...@gmail.com 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 authors, but I'd like to make it clear that I think it is very important that Stuart's book correspond to a release of Clojure. It would be huge for newcomers coming to Clojure find a book that says Covers Clojure 1.0, and a compatible download for 1.0.x with the latest fixes. Stuart has worked hard on tracking the latest changes, as have I in trying to get in those changes that would be breaking as soon as I could before 1.0. I'm presuming it's not too late to get Covers Clojure 1.0 in there (Stuart?), and, if so, it is a factor in this decision. I'll also add that there is plenty more I'd like to do, and as soon as I get into that trunk will again be changing rapidly. There simply has to be a branch for fixes only. As to the feedback: 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. Advantages of Maven vs Ivy vs whatever should be separate. 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 in the language itself. A deprecation policy is a good idea. Backward compatibility mode is unlikely. 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. 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. Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 merged into trunk. Subversion should NOT be used. Branching and merging are too difficult. Distributed version contol makes this much easier. Now, the issue of Rich's preferences comes in. Obviously, the current development practices have worked pretty damn well so far. Perhaps there is a way to allow the current SVN trunk to stand, and have changes from there merged into another system for testing and distribution. That would make SVN a private repository, for the most part. Details would need to be worked out, but I think it's an avenue worth exploring. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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. But that's not a show stopper, it's been like that for years with most compilers/languages I worked with. The time to release another official build may be a bit longer to bundle the list of changes. It does not have to be fancy but maybe the comments added to each SVN version should be expanded a bit to be more accessible to mere mortals. That could be the basis for release notes. Attaching bug reports to release notes maybe harder, I do not see how you can achieve that with Google code. c) Clojure is unfinished ? Well that has been the state of most software languages and tools for years. Will new enhancements require changes to the core ? Maybe, maybe not. Considering the available mechanisms built in Clojure to extend itself, I do not see why we should worry now about this, except if Rich has another grandiose idea in the back of head that we are not aware of : (Rich, maybe you should then consider creating another dialect ? : Considering the growing pains we faced with Java in the last 9 years, I think enhancing Clojure will be a breeze compared to the maelstrom of JVM bugs, compatibility issues and behaviour changes with had to deal with. d) Test suite ? Covering all cases is a long term task in any programming language and just figuring out all these cases would postponed 1.0 for months. Adding test cases along the way is the only practical alternative. Maybe we should go with the requirement that a bug report should include a usable test case. That would at least reduce the work of the person doing/integrating the fix in the code. e) Is the current test framework fine ? Well until we think about something else better, we should stick with it and just enrich that with test cases. Maybe we should adopt a test numbering that matches bug reports and use that to update the existing test suites and track things. No need for some heavy stuff, bare comments are enough. At least that stuff will be documented somewhere. f) Contrib library management ? That should be a top priority but Rich is right getting this out in 1.0 is a tall order and people do not seem to agree on what should be used. Personally, I think there are enough tools out there and inventing another one is superfluous. I can understand why gems were created, I can understand the need for Lancet but creating another Clojure-like maven ? Why not use something already there and put our energy on more Clojure centric stuff ? g) Changing the source code management tool ? Not a priority. How many people to we expect to play on the core ? If we say that 500 people will make changes ok, we may have a problem with SVN and GIT might be better at it. But I do not think we are there and I do not see that as a great idea (having hundreds of people working on the core). Google code does the job so far, lets build on that. Being afraid of committing to practises/tools is worst than moving forward. We could wait for months/years juggling with what is the best thing to commit to. Let's learn by mistakes a bit here... Each year there will be a greater test framework/build tool/etc... but somehow we have to make choices now... Rich, maybe it's time to establish, following that 1.0 release, a set of priorities ? I think we need some dictatorship here and you are the best candidate from my point of view. The idea is not to put more pressure/work on your shoulders but making sure the delegation process is efficient to make Clojure move forward. You seem to have other concepts to integrate in Clojure and that should remain your main responsibility but for all the other stuff you could establish the priorities and guidelines to follow. Then the community could tackle these things in an orderly fashion. Consensus can be a great thing but often it costs precious time... Luc On Fri, 2009-04-17 at 06:21 -0700, 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 authors, but I'd like to make it clear that I think it is very important that Stuart's book correspond to a release of Clojure. It would be huge for newcomers coming to Clojure find a book that says Covers Clojure 1.0, and a compatible download for 1.0.x with the latest fixes. Stuart has worked hard on tracking the latest changes, as have I in trying to get in those changes that would be breaking as soon as I could before 1.0. I'm presuming it's not too late to get Covers Clojure 1.0 in there (Stuart?),
Re: The Path to 1.0
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 another. Bug fixes to version 1.0 would be nice too, but the main point is having the same behavior described in version 1.0 and in the book. Should it be necessary, the book could refer to features coming for version 1.1. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Fri, Apr 17, 2009 at 9:21 AM, Rich Hickey richhic...@gmail.com wrote: snip 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 have a test suite with the Clojure code. That way the suite is branched with the Clojure code. If a 1.0 branch is created in the Clojure code, then how does the test-clojure suite relate to that? Would there be a 1.0 branch made of clojure-contrib, too? Would there be any assurance that version X of the test-clojure suite can be run against version X.Y of Clojure to verify there were no regressions? And on clojure-contrib in general, I think maybe there needs to be a better definition of what its scope is. Just because I have cool-whizz-bang Clojure library does it mean that cool-whizz-bang should be made part of clojure-contrib? clojure-contrib is for user contributed code, but just any code at all? As others have mentioned, clojure-contrib seems to include some things that might warrant separate projects (like ClojureScript and ClojureCLR). I don't see a problem with people creating Clojure libraries and distributing them apart from clojure-contrib, but of course as soon as the code starts to get distributed in different channels, you have the dependency management issue. (ugh!) 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. I don't think that feature requests preclude a 1.0 release. I think all that is warranted is partitioning the feature requests into releases. 1.0 will include x, y, and z (and are labeled with Release-1.0 in the issue tracker). 2.0 will include a, b, and c (and are labeled so). As soon as x, y, and z are completed, then you cut a 1.0 release. (*brushes off hands* Now we start on 2.0.) Of course you would have the flexibility (within reason) of shifting features to earlier or later releases. If a bug fix comes in, and it is determined that it should be backported from trunk to the 1.0 branch, then label it so in the issues tracker, and the 1.0 release captain can modify the test suite, and cut a 1.0.1 release. There is already a list of Primary Contributors on the clojure.org site. I nominate them as release captains :). I don't think that Rich needs to be bothered with that sort of thing. I hesitate to say this, but if no one else will do it, then I'll volunteer, since I got a pretty good idea of the inner workings of Clojure with my Terracotta work. All that said, Rich, don't feel rushed into making decisions about this. If you're not comfortable, cutting a 1.0 release and starting the whole release management process, then don't. It's getting close, but maybe it's not time just yet. However, I don't think it's a matter of having to stop progress, but just to create check points along the way, and to give people that psychological ease of seeing 1.0. Paul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 necessarily to block 1.0 IMO. When I release software that depends on Clojure I pin it to a commit number, not to a named release. For me the named release is more about public recognition than anything else. Cheers, Stu P.S. Git is to svn as functional languages are to mutable languages. Git repositories are immutable data structures, and repos-local pointers such as HEAD are like atoms. It would be interesting to see Clojure's data structures have a canonicalized serialization and play around with content addressability. When we release software that depends on Clojure we don't care about numbered releases at all -- we will run regression tests of our own production app against the Clojure and contrib repositories and pin our releases to a commit number, not a specif 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. - 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? 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 17, 9:21 am, Rich Hickey richhic...@gmail.com 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 in the language itself. I wonder if git-svn could be used so that git could be used and the google code repository treated as a central hub? A quick google for git svn google code turned up several interesting results, including a few posts from one of Google's blogs [1]. Also, GitHub recently added issue tracking. - 1 http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 get though. On Fri, Apr 17, 2009 at 11:42 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: 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 necessarily to block 1.0 IMO. When I release software that depends on Clojure I pin it to a commit number, not to a named release. For me the named release is more about public recognition than anything else. Cheers, Stu P.S. Git is to svn as functional languages are to mutable languages. Git repositories are immutable data structures, and repos-local pointers such as HEAD are like atoms. It would be interesting to see Clojure's data structures have a canonicalized serialization and play around with content addressability. When we release software that depends on Clojure we don't care about numbered releases at all -- we will run regression tests of our own production app against the Clojure and contrib repositories and pin our releases to a commit number, not a specif 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. - 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? 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 -- John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 don't have to bother too much with: * release-quality documentation * release-quality tests (because you obviously didn't need them much until now) * release planning * release press coverage, interviews such ...so that you can continue improving our baby as fast as you're used to. Therefore, if you can find a way to fit in the former without hindering you too much for the latter, I'm 100% supporting for a 1.0 cut. Why? Because I've heard quite a few business deciders mention that we're waiting for a 2.0 release. Consequently, I think it would be great to see a 1.0 release today so that we can see a 2.0 release sooner than later. :) But not at the cost of your ability to thrive at clojure's development. That said, I'm definitely dedicating more and more of my time to clojure. I'm willing to help with the former (doc tests, as soon as I'm ready) to help you focus on the latter. For this reason, although I would prefer that clojure's tests be part of the core not the contrib, I understand that it suits you better like it is for now, and I support that. The same could be said of all the other issues that have been mentioned, as long as they help you focus. Whatever you decide, I'll definitely support your call. Finally, the only thing that I ask of you, in support to Luc Préfontaine, is for you to write up some priorities for us to help you better. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 that release, as long as it's stable and useful. But I'd like a release of Clojure 1.0 so I can say to people this works with version X, with 100% certainty that we're talking about the exact same feature set. It's hard for new people to get working with Clojure, as it is, because everything is in a constant state of flux and you never know when an upgrade will break Slime, ect. Coherent versioning eliminates this worry. To me, a 1.0 release is all about reducing barriers for newcomers by saying this is definitely safe to use. The only reason NOT to release 1.0 immediately, imho, is if a major change is just around the corner. Thanks, -Luke On Apr 16, 12:53 pm, 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. - 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? 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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. 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 raised so far. Regards, Chris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 17, 8:21 am, Rich Hickey richhic...@gmail.com 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 authors, but I'd like to make it clear that I think it is very important that Stuart's book correspond to a release of Clojure. It would be huge for newcomers coming to Clojure find a book that says Covers Clojure 1.0, and a compatible download for 1.0.x with the latest fixes. Stuart has worked hard on tracking the latest changes, as have I in trying to get in those changes that would be breaking as soon as I could before 1.0. I'm presuming it's not too late to get Covers Clojure 1.0 in there (Stuart?), and, if so, it is a factor in this decision. I'll also add that there is plenty more I'd like to do, and as soon as I get into that trunk will again be changing rapidly. There simply has to be a branch for fixes only. As to the feedback: 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. Advantages of Maven vs Ivy vs whatever should be separate. 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 in the language itself. A deprecation policy is a good idea. Backward compatibility mode is unlikely. As for tests, there are tests in: http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src... Anyone who wants more tests can contribute them. 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. I think you could call it 1.0 now, if you're ready for the kinds of expectations and bug reports that version brings with it.I don't think it is any kind of barrier to further experimentation and development. I do think that you're right to think that slapping a 1.0 label on it means there should be some specific revision that people can download called 1.0, and reasonably expect to get a specific, stable set of features. Clozure Associates went through this exact discussion a couple years ago when it considered whether to designate the next release of OpenMCL (now called CCL) as 1.0. It had pretty much the same set of considerations. In the end, Clozure did adopt the 1.0 designation, and I think on the whole the effect has been positive; it helped bring the general perception of CCL's maturity closer to the reality. Go ahead and call Clojure 1.0, when you're ready to make sure there's a 1.0 release people can download, and when you're ready for an influx of bug reports from new users who are confused by foiled preconceptions. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Thu, Apr 16, 2009 at 11:53 AM, Rich Hickey richhic...@gmail.com 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 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. This is actually something that I am interested in doing (porting fixes from trunk to 1.0) so I would love to help with that process once we get to 1.0 -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 google code over it (aside from the learning curve). Mike On Apr 17, 6:21 am, Rich Hickey richhic...@gmail.com 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 authors, but I'd like to make it clear that I think it is very important that Stuart's book correspond to a release of Clojure. It would be huge for newcomers coming to Clojure find a book that says Covers Clojure 1.0, and a compatible download for 1.0.x with the latest fixes. Stuart has worked hard on tracking the latest changes, as have I in trying to get in those changes that would be breaking as soon as I could before 1.0. I'm presuming it's not too late to get Covers Clojure 1.0 in there (Stuart?), and, if so, it is a factor in this decision. I'll also add that there is plenty more I'd like to do, and as soon as I get into that trunk will again be changing rapidly. There simply has to be a branch for fixes only. As to the feedback: 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. Advantages of Maven vs Ivy vs whatever should be separate. 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 in the language itself. A deprecation policy is a good idea. Backward compatibility mode is unlikely. As for tests, there are tests in: http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src... Anyone who wants more tests can contribute them. 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. Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 in the community ) 2009/4/17 mifrai fraim...@gmail.com 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 google code over it (aside from the learning curve). Mike On Apr 17, 6:21 am, Rich Hickey richhic...@gmail.com 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 authors, but I'd like to make it clear that I think it is very important that Stuart's book correspond to a release of Clojure. It would be huge for newcomers coming to Clojure find a book that says Covers Clojure 1.0, and a compatible download for 1.0.x with the latest fixes. Stuart has worked hard on tracking the latest changes, as have I in trying to get in those changes that would be breaking as soon as I could before 1.0. I'm presuming it's not too late to get Covers Clojure 1.0 in there (Stuart?), and, if so, it is a factor in this decision. I'll also add that there is plenty more I'd like to do, and as soon as I get into that trunk will again be changing rapidly. There simply has to be a branch for fixes only. As to the feedback: 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. Advantages of Maven vs Ivy vs whatever should be separate. 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 in the language itself. A deprecation policy is a good idea. Backward compatibility mode is unlikely. As for tests, there are tests in: http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src... Anyone who wants more tests can contribute them. 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. Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Fri, Apr 17, 2009 at 6:21 AM, Rich Hickey richhic...@gmail.com 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 source. I'm all for feature requests, but it's worth keeping in mind that some feature requests make more sense at this stage than others. I'd like to see 1.0 include the sorts of feature requests that people have made that complete, round out, or refine the existing functionality. For example things that have been suggested here like: * compare should work on lists and sequences, doing lexicographic comparison like vectors * merge functionality of repeat and replicate into one function and deprecate the other. * figure out what contrib functions should belong in the core. It seems like once those sorts of changes have been made, it's worth stamping a 1.0 label on everything before plowing ahead with the more visionary changes such as streams, multimethod enhancements, distributed systems, etc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 version number (e.g. 1.0.0) and the subversion number (e.g. r1352) in the built clojure.jar somewhere that's easily accessible to tools that are trying to do library management. My solution to this would probably just be to generate a couple of (def *clojure-version- number* 1.0.0) things as part of the build. Do any Java/Maven heads have more sophisticated ideas that we should consider here? I've just started hacking on some svn manipulation stuff (and a little bit of jar manipulation) in the process of doing my contrib autodoc robot, so I'd be happy to help here too. 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 need to address that. (To my mind, the python library has always felt very ad hoc.) I do not agree with John Newman that the Java standard library should be the Clojure standard library. There's enough that's different in Clojure that I think we do want some of our own ways to approach things. I think there's also space for some great documents ( screencasts, etc.) that show how to leverage parts of the Java library to do cool things in Clojure. (Rich's demo of building swing apps in Clojure comes to mind.) I'd also like to see a little more focus on the perl/python/ruby equivalence from a newbie perspective. That is, more clarity around startup, script execution (including having an equivalent to python's if __name__ == '__main__': construct), class path management, etc. I know that this is one area where being in the JVM ecosystem makes our life worse rather than better, but approaching Clojure is still a bit daunting compared to these other languages. You can count me among the git fanboys, but I can't get too worked up about moving off google code right now (and that would be necessary if we switched to git). (Aside to Matt Revelle: You can use git-svn on the client side (and I do) but that provides only a local solution, so it isn't a magic bullet.) Really, we all know that 1.0 means 1.0. Clojure will be much further along than most other languages at their 1.0 point, so I wouldn't stress over it too much. I think that might have been 6 cents worth :-). Tom --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/17 Laurent PETIT laurent.pe...@gmail.com: 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 last thing we want to do is start flame wars on Git Vs Mercurial (for example) - that is pointless. There are many credible comparisons between specific VCSs (the Python PEP 374 I mentioned earlier in this thread being one of them). The question for me is whether it's important to move to a *distributed* VCS and not so much which one to pick. Having thought a bit more on it, while I would like to see a move to a DVCS personally, I don't think it's important in the context of a 1.0 release. I think it's a completely separate issue. -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne Wear, DH5 8NE. This message is intended only for the use of the person(s) (the intended recipient(s)) to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/17 Tom Faulhaber tomfaulha...@gmail.com: 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 need to address that. (To my mind, the python library has always felt very ad hoc.) One of the best things about the Python library being batteries-included is that it's easy for newcomers to get started. I'd also like to see a little more focus on the perl/python/ruby equivalence from a newbie perspective. That is, more clarity around startup, script execution (including having an equivalent to python's if __name__ == '__main__': construct), class path management, etc. I know that this is one area where being in the JVM ecosystem makes our life worse rather than better, but approaching Clojure is still a bit daunting compared to these other languages. This is one of the main problems with clojure-contrib for me. I think it would be awkward to have a 1.0 release with clojure-contrib left as is and would cause confusion for newcomers. Unless I am mistaken there are still many open questions regarding how clojure-contrib is integrated with clojure such as its dependency relationship with clojure.jar for example. Surely, this sort of thing needs ironing out before a 1.0 release? I think various comments in the following recent thread summarises some of the main issues well: http://groups.google.com/group/clojure/browse_thread/thread/9cd8dbe421285be7/eae77c266022dc5e?lnk=raot Paul. -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne Wear, DH5 8NE. This message is intended only for the use of the person(s) (the intended recipient(s)) to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 laurent.pe...@gmail.com 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 sure whether clojure needs those kinds of nonsense internal wars in the community ) 2009/4/17 mifrai fraim...@gmail.com 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 google code over it (aside from the learning curve). Mike On Apr 17, 6:21 am, Rich Hickey richhic...@gmail.com 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 authors, but I'd like to make it clear that I think it is very important that Stuart's book correspond to a release of Clojure. It would be huge for newcomers coming to Clojure find a book that says Covers Clojure 1.0, and a compatible download for 1.0.x with the latest fixes. Stuart has worked hard on tracking the latest changes, as have I in trying to get in those changes that would be breaking as soon as I could before 1.0. I'm presuming it's not too late to get Covers Clojure 1.0 in there (Stuart?), and, if so, it is a factor in this decision. I'll also add that there is plenty more I'd like to do, and as soon as I get into that trunk will again be changing rapidly. There simply has to be a branch for fixes only. As to the feedback: 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. Advantages of Maven vs Ivy vs whatever should be separate. 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 in the language itself. A deprecation policy is a good idea. Backward compatibility mode is unlikely. As for tests, there are tests in: http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src... Anyone who wants more tests can contribute them. 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. Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Fri, Apr 17, 2009 at 4:29 PM, Laurent PETIT laurent.pe...@gmail.comwrote: 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 in the community ) We seem to be unanimous in preferring git. In the meantime, I'm using svn-git to track clojure's official repo. The whole history of clojure is a mere 2 megabytes. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 then I would delay 1.0 for as long as possible. However, if you want to bring on wide adoption, which I think you do, then I think it is *IMPERATIVE* that the front of Stu's book includes the text Works for Clojure 1.0. It is my opinion that if Programming Clojure goes to print without that text Clojure, as a community and a language, loses a lot of potential users! It isn't a big deal to bleeding-edge folks like ourselves, but we are a *MINORITY*. And a minority is all we will be if we think in minor terms. I agree with a lot of what has been said here, but I feel Stu's book release should be at the top of the list. It's Clojure's first impression on the global community of developers, and we all know the rule about first impressions. I vote pragmatism, lets get this sucker rolling! -Ryan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 the bad aspects, are of course, some things I would like to see more polished before releasing a 1.0. By polished, I don't necessary am asking for still adding more functionality, but cleaning up things here and there. Especially, removing complexity where it's not needed would be good, because it eases the learning curve for newcomers. I'm thinking here of the ns - lib somewhat unneeded distinction, which may cause newcomers halt to think about it for (I think) no good reason. Something like : Wait, in the ns doc, they speak about something called a lib-spec. Lib definitely looks like the prefix of library, so there must be the concept of library in clojure. Where is it ? ... search ... search ... search well it doesn't seem to me that there is stuff related to library in a way that it differs from stuff related to namespaces think ... think ... think ... is it me that doesn't understand something ? ... think ... think ... is it just over engineering . Multiply the above thoughts by the number of newcomers. If I'm right, I am candidate to submit patches for removing lib-spec from clojure source, clojure-contrib and wiki documentation. Regards, -- Laurent 2009/4/16 Rich Hickey richhic...@gmail.com 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. - 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? 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 17, 9:21 am, Rich Hickey richhic...@gmail.com 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. :) But it's worth thinking about, given the level of interest recently. I don't care about git/svn/whatever. It's pretty easy to bridge between them these days. -Stuart Sierra --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
2009/4/18 Laurent PETIT laurent.pe...@gmail.com: [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 myself and so don't have any preference regarding Mercurial Vs Git Vs any-other-DVCS-out-there. As I mentioned earlier, I think Clojure should use a *distributed* VCS one day (the sooner the better) but - importantly - that decision isn't relevant to a 1.0 release. Paul. -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne Wear, DH5 8NE. This message is intended only for the use of the person(s) (the intended recipient(s)) to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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. Using clojure.contrib is in fact extremely easy, but it's hard to tell that from the point of view of a new user. I was a new user recently enough to remember my initial confusion about how to set up my development environment and how to arrange it so that clojure.contrib was as readily accessible as it should be. I wasn't talking about how to get it on the classpath so much as documentation for the individual components in clojure-contrib. IMO those components should be broken out, and documented. I have commercial experience developing Smalltalk applications which has shown me that you *can* survive without extensive documentation iff you have fantastic code navigation and exploration. I'm not talking about find-doc et al, but some way of navigating live code. So when I say that documentation is necessary, I admit that one alternative would be a code navigation tool as part of the core. One way to do this would be an ultra-lightweight server as part of core that serves up a hyperlinked cross-ref view of the source, ala the Smalltalk Browser. I don't think this should be relegated to the individual IDEs. The weakness of the Smalltalk approach as compared to javadoc (say) is that it's easy to cop out and regard functional-level documentation is being sufficient, whereas you also require architectural/expository documentation, and that really needs to be rich e.g. package level javadoc as opposed to class/method level documentation. I think some mechanism to do that is required. My overall point being that there is a conflict in knowing that documentation is absolutely required for mass-acceptance and arms- length use and yet knowing that documentation generally won't be written and even when it is, it needs to be integrated. IMO javadoc is a significant reason for the success of java, and something at least as good, and preferably live and reflective, is required for Clojure. I get the feeling that for the purposes of a book about the language, 1.0 is pretty much ready now, although wasn't there something about method dispatch / hierarchies that Rich was looking at? Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B will do it very easily and for a very reasonable price, but I don't want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and $CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas on how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct tape, an iPod, and hours and hours of my precious time. -- Slashdot response to an enquiry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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 the Clojure site made it very easy to open a REPL via a call to `java -cp ...`, it was much less clear how to make a simple command-line tool that could be run from anywhere to open a REPL, or run/compile a script. There is a bash script in clojure-contrib that does some of this and it would make sense to put this and maybe a similar Windows .BAT script in a 1.0 release. Along these line, most other languages I've used come with an optional installer for each major OS that sets up a standard operating environment including command-line tools and a library structure. Maybe Clojure 1.0 could have something similar? Compared to Javadoc documentation, I find the current Clojure API documentation a little terse and unorganised. In particular, I don't find the large table of contents bar down the side of http://clojure.org/api very useful. Some of the clojure.org pages, such as http://clojure.org/data_structures , have collections of related functions which I found very useful when feeling my way around the standard library. Perhaps this sort of thing could be formalised, extended and put into some easily navigable format? Though it is not as important, I've also had very good experiences with Git and GitHub after having used CVS and subversion for many years. I think the social infrastructure they created at GitHub adds a lot of value to Git as a SCM tool. I also agree with several of the other posters about a 1.0 release to coincide with Stuart's book. Regards, Mark Reid -- http://mark.reid.name --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
There's no way to get fixes without also getting enhancements unless you use a non-linear source control like Git. (please switch?) :) Ok no flames please - but since we have switched to Git nearly 2 years ago we have been blessed with it's abilities to keep a stable branch master and a RC branch next going with the freedom to try anything in the background (topic branches). Branching is easy, cheap and fun and I create a branch for every new bugfix or feature. It's a thing of beauty and I could never go back to SVN or CVS. I would switch to Hg first (badomp bomp *ching*) :) Just my $0.02 On Apr 16, 6:53 am, Rich Hickey richhic...@gmail.com 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 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Source Control ( Was: Re: The Path to 1.0 )
Also a benefit of being on Git for contrib would mean I don't have to pull ClojureCLR and other stuff I don't want into my clone. It would make it less kitchen junk drawer. Another benefit of being on Git is people can fork, fix and send you pull requests (which you can accept or not at your discretion). It just encourages easy fork/branch/collaborate. On Apr 16, 7:33 am, dysinger dysin...@gmail.com wrote: There's no way to get fixes without also getting enhancements unless you use a non-linear source control like Git. (please switch?) :) Ok no flames please - but since we have switched to Git nearly 2 years ago we have been blessed with it's abilities to keep a stable branch master and a RC branch next going with the freedom to try anything in the background (topic branches). Branching is easy, cheap and fun and I create a branch for every new bugfix or feature. It's a thing of beauty and I could never go back to SVN or CVS. I would switch to Hg first (badomp bomp *ching*) :) Just my $0.02 On Apr 16, 6:53 am, Rich Hickey richhic...@gmail.com 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 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? I would like to see, concurrent with 1.0, some kind of library management system. As noted before, contrib is already getting hairy. We have dozens of little libraries floating around on GitHub. Having you, Rich, maintain the list of libraries on clojure.org is not sustainable. We don't need a fully-realized CPAN/RubyGem but we need something that can scale to a few hundred authors. Dependency management and documentation markup are components of this. -Stuart Sierra --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
It sounds nice, but I experienced massive amounts of pain trying to get the eclipse git plugin to work on mac ... eventually punted back to SVN. To me version control should be well integrated with an editor ... bottom line ... much more important than the given features of the version control system. On Thu, Apr 16, 2009 at 10:33 AM, dysinger dysin...@gmail.com wrote: There's no way to get fixes without also getting enhancements unless you use a non-linear source control like Git. (please switch?) :) Ok no flames please - but since we have switched to Git nearly 2 years ago we have been blessed with it's abilities to keep a stable branch master and a RC branch next going with the freedom to try anything in the background (topic branches). Branching is easy, cheap and fun and I create a branch for every new bugfix or feature. It's a thing of beauty and I could never go back to SVN or CVS. I would switch to Hg first (badomp bomp *ching*) :) Just my $0.02 On Apr 16, 6:53 am, Rich Hickey richhic...@gmail.com 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 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Source Control ( Was: Re: The Path to 1.0 )
On Thu, Apr 16, 2009 at 10:39 AM, dysinger dysin...@gmail.com wrote: Also a benefit of being on Git for contrib would mean I don't have to pull ClojureCLR and other stuff I don't want into my clone. It would make it less kitchen junk drawer. Another benefit of being on Git is people can fork, fix and send you pull requests (which you can accept or not at your discretion). It just encourages easy fork/branch/collaborate. making the common case easy is important. I like good branching, too, for when you need it, but is it the common case, or does it fly in the face of what we are talking about here? On Apr 16, 7:33 am, dysinger dysin...@gmail.com wrote: There's no way to get fixes without also getting enhancements unless you use a non-linear source control like Git. (please switch?) :) Ok no flames please - but since we have switched to Git nearly 2 years ago we have been blessed with it's abilities to keep a stable branch master and a RC branch next going with the freedom to try anything in the background (topic branches). Branching is easy, cheap and fun and I create a branch for every new bugfix or feature. It's a thing of beauty and I could never go back to SVN or CVS. I would switch to Hg first (badomp bomp *ching*) :) Just my $0.02 On Apr 16, 6:53 am, Rich Hickey richhic...@gmail.com 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 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? To me, beside what was already said, it means a deprecation policy. I like Python's. First release after deprecated changes are decided, code works as is but produces warning if you run it under warning mode. Second release, warning will come warning mode or not and third release, the feature is cut. Ideally, since backward compatibility is a big selling point of Java, I'd like to be able to tell clojure I require say version 1.0 and get the 1.0 behaviour even if I'm running on a newer version. It would enable the language to grow while providing a nice compatibility layer. Unless that's too hard or there is ramifications I'm not seeing. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
Ideally, since backward compatibility is a big selling point of Java. my view of Java's backward compatibility is that it is kind of a bunch of hot air that restricts the ecosystem from being better. i vastly prefer the fact that .net is willing to make real changes to get real benefits. sincerely. $0.02 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Apr 16, 2009, at 1:56 PM, Stuart Sierra wrote: On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? I would like to see, concurrent with 1.0, some kind of library management system. As noted before, contrib is already getting hairy. We have dozens of little libraries floating around on GitHub. Having you, Rich, maintain the list of libraries on clojure.org is not sustainable. We don't need a fully-realized CPAN/RubyGem but we need something that can scale to a few hundred authors. Dependency management and documentation markup are components of this. +1. I worry about the cpan/gem mention, though. We're still in the java world w.r.t. build and packaging, which generally means using something like ivy/maven/svn:externals/git-submodule/etc ahead of one's build process, rather than using cpan/gem/easy_install/etc at deployment time. That said, I have no concrete suggestion, as we'll always separately pull our projects' dependencies into whatever we happen to be using as a dependency management repo (it's a bummer to not be able to run a build if some third-party repo is down, etc). Regarding documentation, I remember throwing around ideas in irc some months ago about how to fold documentation from gen-class'ed libs into a library's broader javadoc. That would be a huge boon to those using clojure to build libraries that would be transparently usable by Java developers. - Chas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
I am all for a standard packaging/build system but what ever it is it needs to not ignore the 10s of thousands of libraries tucked away in maven2 repos. Something like Ties w/ compile support would be cool. Git submodules, SVN externals Hg forrest won't work either because everyone uses different source control (and sorry I am not switching off git :P ). On Apr 16, 9:10 am, Chas Emerick cemer...@snowtide.com wrote: On Apr 16, 2009, at 1:56 PM, Stuart Sierra wrote: On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? I would like to see, concurrent with 1.0, some kind of library management system. As noted before, contrib is already getting hairy. We have dozens of little libraries floating around on GitHub. Having you, Rich, maintain the list of libraries on clojure.org is not sustainable. We don't need a fully-realized CPAN/RubyGem but we need something that can scale to a few hundred authors. Dependency management and documentation markup are components of this. +1. I worry about the cpan/gem mention, though. We're still in the java world w.r.t. build and packaging, which generally means using something like ivy/maven/svn:externals/git-submodule/etc ahead of one's build process, rather than using cpan/gem/easy_install/etc at deployment time. That said, I have no concrete suggestion, as we'll always separately pull our projects' dependencies into whatever we happen to be using as a dependency management repo (it's a bummer to not be able to run a build if some third-party repo is down, etc). Regarding documentation, I remember throwing around ideas in irc some months ago about how to fold documentation from gen-class'ed libs into a library's broader javadoc. That would be a huge boon to those using clojure to build libraries that would be transparently usable by Java developers. - Chas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
my view of Java's backward compatibility is that it is kind of a bunch of hot air that restricts the ecosystem from being better. i vastly prefer the fact that .net is willing to make real changes to get real benefits. sincerely. $0.02 And that requires shoe-horning new stuff in the old framework like using that $ convention for inner classes for instance, I agree. I did not suggest the language and API should not change and remain forever compatible, only that if possible, instead of doing something like this: (if ( *clojure-version* 1.0) (do-something) (do-something-else)) I could do something like: (ns my-namespace (:clojure-version 1.0)) and expect clojure to reroute through the old code and the old api. Clojure would stay free to evolve. The question is whether or not the cost of maintaining the plumbings to require old APIs is worth the cost. I am not really apt to judge what it involves so I'll wait for others to enlighten me. If it's not worth the cost, I'd be happy with a works-perfectly, warns, gone deprecation policy. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
OSGi is becoming the de facto standard for solving the runtime issues around versioning and classpath management in the standard Java world. As for development versioning issues, Maven is the de facto standard. While I certainly don't think that Clojure 1.0 should have any dependency on OSGi, I'd personally like to see the libraries evolve that direction with some library API support. The API support would likely parallel the OSGi jar manifest declarations. That API could serve both as build time code to generate the static manifest files necessary to play in an OSGi container as well as runtime declarations of services and dynamic dependencies. On Apr 16, 12:28 pm, Dan redalas...@gmail.com wrote: my view of Java's backward compatibility is that it is kind of a bunch of hot air that restricts the ecosystem from being better. i vastly prefer the fact that .net is willing to make real changes to get real benefits. sincerely. $0.02 And that requires shoe-horning new stuff in the old framework like using that $ convention for inner classes for instance, I agree. I did not suggest the language and API should not change and remain forever compatible, only that if possible, instead of doing something like this: (if ( *clojure-version* 1.0) (do-something) (do-something-else)) I could do something like: (ns my-namespace (:clojure-version 1.0)) and expect clojure to reroute through the old code and the old api. Clojure would stay free to evolve. The question is whether or not the cost of maintaining the plumbings to require old APIs is worth the cost. I am not really apt to judge what it involves so I'll wait for others to enlighten me. If it's not worth the cost, I'd be happy with a works-perfectly, warns, gone deprecation policy. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
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
Re: The Path to 1.0
On Thu, Apr 16, 2009 at 9:10 PM, Chas Emerick cemer...@snowtide.com [...] That said, I have no concrete suggestion, as we'll always separately pull our projects' dependencies into whatever we happen to be using as a dependency management repo (it's a bummer to not be able to run a build if some third-party repo is down, etc). Yes, please, I don't want to be forced to work around automated downloaders. e.g. Like OpenWrt's build system that wants to download huge amounts of code if you don't watch it instead of just failing so you can tell it to look *over there* where I've already downloaded 90% of it! Of course, after it happens the first time you learn to be more careful, but I would prefer to be told what the dependencies are so that I can get them myself, or to be asked whether to download them than just automatically downloading them. Regarding documentation, I remember throwing around ideas in irc some months ago about how to fold documentation from gen-class'ed libs into a library's broader javadoc. That would be a huge boon to those using clojure to build libraries that would be transparently usable by Java developers. About documentation: I believe this has been mentioned before, but I haven't been able to find the thread. Some functions are documented like this: assoc[iate]. When applied to a map[...] This makes it difficult if you're looking for some function and don't know the exact name. e.g.: user= (find-doc quotient) nil user= (find-doc quot\\[ient) - clojure.core/quot ([num div]) quot[ient] of dividing numerator by denominator. nil Also, while looking for the thread mentioning the above, I found another unresolved documentation-related thread: http://groups.google.com/group/clojure/browse_thread/thread/9d18bc892ff523d5/b21c03cfb26ea084#b21c03cfb26ea084 This is about the count function being difficult to find if you're trying to find the length or size of something. -- Michael Wood esiot...@gmail.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: The Path to 1.0
On Thu, Apr 16, 2009 at 7:56 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? I would like to see, concurrent with 1.0, some kind of library management system. As noted before, contrib is already getting hairy. We have dozens of little libraries floating around on GitHub. Having you, Rich, maintain the list of libraries on clojure.org is not sustainable. We don't need a fully-realized CPAN/RubyGem but we need something that can scale to a few hundred authors. Dependency management and documentation markup are components of this. Python did very well without a CPAN-alike. Of course it had a pretty good standard library. -- Michael Wood esiot...@gmail.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
