Re: The Path to 1.0

[Laurent PETIT]

2009/5/4 Phil  Hagelberg :
>
> On May 2, 1:02 am, Laurent PETIT  wrote:
>> > > Note: I strongly suggest that the clojure.version.interim property
>> > > remains true in svn, so that it's not possible to inadvertently
>> > > release a version "too early".
>>
>> > Just to clarify - are you 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

[Phil Hagelberg]

On May 2, 1:02 am, Laurent PETIT  wrote:
> > > Note: I strongly suggest that the clojure.version.interim property
> > > remains true in svn, so that it's not possible to inadvertently
> > > release a version "too early".
>
> > Just to clarify - are you 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

[Laurent PETIT]

2009/5/1 Rich Hickey 

>
>
>
> On Apr 26, 6:54 pm, Laurent PETIT  wrote:
> > I've created issue 110 with the patch attached in clojure's google code
> project.
> >
> >
> > Note: I strongly suggest that the clojure.version.interim property
> > remains true in svn, so that it's not possible to 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

[Rich Hickey]

On Apr 26, 6:54 pm, Laurent PETIT  wrote:
> I've created issue 110 with the patch attached in clojure's google code 
> project.
>
>
> Note: I strongly suggest that the clojure.version.interim property
> remains true in svn, so that it's not possible to 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

[Meikel Brandmeyer]

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

[Laurent PETIT]

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 :
>
> 2009/4/28 Laurent PETIT :
>>
>> 2009/4/28 Marko Kocić :
>>>
>>> Shouldn't "ant clean" remove all generated files, including jars from
>>> the source tree?
>>
>> I also asked this to myself, but it was the previous behaviour and I
>> didn't want to do more than one thing in the patch.
>
> "ant clean" in the clojure-contrib build tree removes the jars.  I
> think it makes sense to do the same for clojure.
>
> --
> Michael Wood 
>
> >
>

--~--~-~--~~~---~--~~
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 @@
   
 
+
+  
+
+  
+
 
   
 

Re: The Path to 1.0

[Rich Hickey]

On Apr 28, 9:41 am, Laurent PETIT  wrote:
> Hi,
>
> 2009/4/28 Rich Hickey :
>
>
>
> > On Apr 27, 5:01 pm, Laurent PETIT  wrote:
> >> New patch with corrections posted to google code,
>
> > That patch has been applied. I recommend everyone who is able to
> > please try out the latest version from 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).
>

Patch applied (svn 1359) - 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

[Michael Wood]

2009/4/28 Laurent PETIT :
>
> 2009/4/28 Marko Kocić :
>>
>> Shouldn't "ant clean" remove all generated files, including jars from
>> the source tree?
>
> I also asked this to myself, but it was the previous behaviour and I
> didn't want to do more than one thing in the patch.

"ant clean" in the clojure-contrib build tree removes the jars.  I
think it makes sense to do the same for clojure.

-- 
Michael Wood 

--~--~-~--~~~---~--~~
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]

2009/4/28 Marko Kocić :
>
> Shouldn't "ant clean" remove all generated files, including jars from
> the source tree?

I also asked this to myself, but it was the previous behaviour and I
didn't want to do more than one thing in the patch.

--~--~-~--~~~---~--~~
You 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

[Marko Kocić]

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

[Konrad Hinsen]

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

[Laurent PETIT]

Hi,

2009/4/28 Rich Hickey :
>
>
>
> On Apr 27, 5:01 pm, Laurent PETIT  wrote:
>> New patch with corrections posted to google code,
>>
>
> That patch has been applied. I recommend everyone who is able to
> please try out the latest version from SVN - this will become a
> release candidate. The 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 @@
 
   
 	
+  
+  
+  
   
   
   
@@ -104,6 +107,7 @@
 
   
 
+
   
 
   
   
 
+
   
 
   
 
+
   
 
   

Re: The Path to 1.0

[Rich Hickey]

On Apr 27, 5:01 pm, Laurent PETIT  wrote:
> New patch with corrections posted to google code,
>

That patch has been applied. I recommend everyone who is able to
please try out the latest version from SVN - this will become a
release candidate. The 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 :
>
> > 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:
> > .[.][-][-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 :
>
> >> 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  
> >> wrote:
>
> >>> 2009/4/23 Rich Hickey :
>
>  On Apr 22, 12:41 pm, Laurent PETIT  wrote:
> > 2009/4/22 Rich Hickey :
>
> > > [...]
> > > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>
> > > for interim versions and
>
> > > {:major 1, :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
> >

Re: The Path to 1.0

[Laurent PETIT]

New patch with corrections posted to google code,

regards,

-- 
laurent

2009/4/27 Laurent PETIT :
> I've created issue 110 with the patch attached in clojure's google code 
> project.
>
> Hi Rich, Howard,
>
> I'll answer to both at the same time, trying to reconcile things a bit.
>
> Howard, my 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:
> .[.][-][-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 :
>>
>> 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  
>> wrote:
>>>
>>> 2009/4/23 Rich Hickey :



 On Apr 22, 12:41 pm, Laurent PETIT  wrote:
> 2009/4/22 Rich Hickey :
>
> > [...]
> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>
> > for interim versions and
>
> > {:major 1, :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 f

Re: The Path to 1.0

[David Andrews]

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

[Laurent PETIT]

I've created issue 110 with the patch attached in clojure's google code project.

Hi Rich, Howard,

I'll answer to both at the same time, trying to reconcile things a bit.

Howard, my 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:
.[.][-][-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 :
>
> 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  
> wrote:
>>
>> 2009/4/23 Rich Hickey :
>>>
>>>
>>>
>>> On Apr 22, 12:41 pm, Laurent PETIT  wrote:
 2009/4/22 Rich Hickey :

 > [...]
 > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}

 > for interim versions and

 > {:major 1, :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 

Re: The Path to 1.0

[Rich Hickey]

On Apr 26, 9:18 am, lpetit  wrote:
> On 26 avr, 15:04, Rich Hickey  wrote:
>
> > On Apr 24, 1:57 pm, Howard Lewis Ship  wrote:
>
> > > Another option is for the version number to be in build.xml, and for
> > > it to generate a runtime file (so that Clojure can know its own
> > > version number) 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

[lpetit]

On 26 avr, 15:04, Rich Hickey  wrote:
> On Apr 24, 1:57 pm, Howard Lewis Ship  wrote:
>
> > Another option is for the version number to be in build.xml, and for
> > it to generate a runtime file (so that Clojure can know its own
> > version number) and set the version number inside a generated 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

[Rich Hickey]

On Apr 24, 1:57 pm, Howard Lewis Ship  wrote:
> Another option is for the version number to be in build.xml, and for
> it to generate a runtime file (so that Clojure can know its own
> version number) and set the version number inside a generated pom.xml.
>  You can use Ant resource copying with filters to accomplish both
> these goals.
>
>

Sounds good, if by runtime file you mean a .properties file.

Patch welcome.

Clojure 1.0 (and all to follow it) is waiting for someone to help me
with this, so, any help would be appreciated.

Thanks,

Rich


>
> On Thu, Apr 23, 2009 at 8:24 AM, Laurent PETIT  
> wrote:
>
> > 2009/4/23 Rich Hickey :
>
> >> On Apr 22, 12:41 pm, Laurent PETIT  wrote:
> >>> 2009/4/22 Rich Hickey :
>
> >>> > [...]
> >>> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>
> >>> > for interim versions and
>
> >>> > {:major 1, :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

[Howard Lewis Ship]

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  wrote:
>
> 2009/4/23 Rich Hickey :
>>
>>
>>
>> On Apr 22, 12:41 pm, Laurent PETIT  wrote:
>>> 2009/4/22 Rich Hickey :
>>>
>>> > [...]
>>> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>>>
>>> > for interim versions and
>>>
>>> > {:major 1, :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

[Christophe Grand]

Laurent PETIT a écrit :
> 2009/4/24 Christophe Grand :
>   
>> Konrad Hinsen a écrit :
>> 
>>> What I miss most for a 1.0 release is some idea of how future changes
>>> will be handled, and what Clojure users can safely count on. For
>>> example, every new function added to clojure.core will 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

[Laurent PETIT]

2009/4/24 Christophe Grand :
>
> Konrad Hinsen a écrit :
>> What I miss most for a 1.0 release is some idea of how future changes
>> will be handled, and what Clojure users can safely count on. For
>> example, every new function added to clojure.core will break code
>> that has chosen to use the 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

[Christophe Grand]

Konrad Hinsen a écrit :
> What I miss most for a 1.0 release is some idea of how future changes  
> will be handled, and what Clojure users can safely count on. For  
> example, every new function added to clojure.core will break code  
> that has chosen to use the 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

[Rich Hickey]

On Apr 23, 11:24 am, Laurent PETIT  wrote:
> 2009/4/23 Rich Hickey :
>
>
>
> > On Apr 22, 12:41 pm, Laurent PETIT  wrote:
> >> 2009/4/22 Rich Hickey :
>
> >> > [...]
> >> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>
> >> > for interim versions and
>
> >> > {:major 1, :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.
>

I appreciate the feedback. Ant/maven, property files and builds are
not my area of expertise, so I'm holding off on 1.0 until I can get
some working solution here (from anyone willing/able).

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

[Laurent PETIT]

2009/4/23 Rich Hickey :
>
>
>
> On Apr 22, 12:41 pm, Laurent PETIT  wrote:
>> 2009/4/22 Rich Hickey :
>>
>> > [...]
>> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>>
>> > for interim versions and
>>
>> > {:major 1, :minor 0, :incremental 0}
>>
>> > for releases. :interim 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

[Rich Hickey]

On Apr 22, 12:41 pm, Laurent PETIT  wrote:
> 2009/4/22 Rich Hickey :
>
> > [...]
> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>
> > for interim versions and
>
> > {:major 1, :minor 0, :incremental 0}
>
> > for releases. :interim 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. What
about clojure.jar containing a properties file it reads at load time?
Could the same file be read by the various builds?

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

[Howard Lewis Ship]

I think you can keep the version number in the pom (there's a
 element at the top).

It is pretty easy to access the POM version from Ant; from there you
can create a file containing the version number, and have Clojure read
that file at startup. However, this starts getting into the world of
requiring the Maven Ant Tasks JAR to be present in order for the build
to work.  Just check it into Subversion, I say.

An additional request: have the REPL display the version number at startup.

On Wed, Apr 22, 2009 at 3:49 AM, Rich Hickey  wrote:
>
>
>
> On Apr 21, 12:18 pm, Daniel Jomphe  wrote:
>> Paul Stadig wrote:
>> > Others have commented on the whole groupId, artifactId, etc., etc. But in
>> > terms of the parts of the version number, they are named
>> > ..- as documented here:
>>
>> >http://www.sonatype.com/books/maven-book/reference/pom-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-.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
>
> >
>



-- 
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

[Laurent PETIT]

2009/4/22 Rich Hickey :
> [...]
> {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>
> for interim versions and
>
> {:major 1, :minor 0, :incremental 0}
>
> for releases. :interim tracks the SNAPSHOT segment of the version
> string.
> [...]
> I don't mind the build producing 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 @@
   
   
   
+  
+  
 
   
 
   
   
 
-  
+  
 
 
   
@@ -80,11 +84,37 @@
 
   
 
+  
+
+
+
+
+

Re: The Path to 1.0

[Daniel Jomphe]

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

[Daniel Jomphe]

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.
--~--~-~--~~~---~--~~
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]

OOooops sorry, I mistook "qualifier" for "classifier",

:qualifier seems totally appropriate here, sorry for the noise,

-- 
Laurent

2009/4/22 Laurent PETIT :
> Hi,
>
> 2009/4/22 Rich Hickey :
>> [...]
>> {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
>> [...]
>> Possible
>> 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

[Laurent PETIT]

Hi,

2009/4/22 Rich Hickey :
> [...]
> {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
> [...]
> Possible
> values of :qualifier include :rc, :beta etc,
> and :interim will be true for non-release builds.

I don't think :qualifier is used correctly here (at least if you want
to 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

[Rich Hickey]

On Apr 21, 12:18 pm, Daniel Jomphe  wrote:
> Paul Stadig wrote:
> > Others have commented on the whole groupId, artifactId, etc., etc. But in
> > terms of the parts of the version number, they are named
> > ..- as documented here:
>
> >http://www.sonatype.com/books/maven-book/reference/pom-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-.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

[Laurent PETIT]

2009/4/21 Daniel Jomphe :
>
> Laurent PETIT wrote:
>> >  version: 1.0.0-rc1-SNAPSHOT
>> >  yields:  clojure-1.0.0-rc1-.jar
>> >           (and ...-slim.jar, ...-sources.jar)
>>
>> There it is. But why having "" in the name of the jar,
>> shouldn't it just be "SNAPSHOT" (as far as I remember) ?
>>
>> 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 "" 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

[Daniel Jomphe]

Laurent PETIT wrote:
> >  version: 1.0.0-rc1-SNAPSHOT
> >  yields:  clojure-1.0.0-rc1-.jar
> >           (and ...-slim.jar, ...-sources.jar)
>
> There it is. But why having "" in the name of the jar,
> shouldn't it just be "SNAPSHOT" (as far as I remember) ?
>
> 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 "" 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

[Laurent PETIT]

Hi,

2009/4/21 Daniel Jomphe :
>
>  version: 1.0.0-rc1-SNAPSHOT
>  yields:  clojure-1.0.0-rc1-.jar
>           (and ...-slim.jar, ...-sources.jar)

There it is. But why having "" in the name of the jar,
shouldn't it just be "SNAPSHOT" (as far as I remember) ?

That is:

{ :major 1 :minor 0 :incremental "0-rc1-SNAPSHOT" }
gives version: 1.0.0-rc1-SNAPSHOT
yields:  clojure-1.0.0-rc1-SNAPSHOT.jar
   (and ...-slim.jar, ...-sources.jar)
-- 
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]

Paul Stadig wrote:
> Others have commented on the whole groupId, artifactId, etc., etc. But in
> terms of the parts of the version number, they are named
> ..- as documented here:
>
> http://www.sonatype.com/books/maven-book/reference/pom-relationships-...

Thanks for the info.

So I was wrong in 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-.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

[Howard Lewis Ship]

On Sat, Apr 18, 2009 at 5:34 AM, Isak Hansen  wrote:
>
> On Thu, Apr 16, 2009 at 6:53 PM, Rich Hickey  wrote:
>>
>> Feedback welcome,
>>
>
> 1. I'd like to see a road map of sorts; plans for where Clojure will
> be going with the next couple of releases.
>
> 2. Clojure-contrib -cleanup
>  - Move 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 .

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]

On Mon, Apr 20, 2009 at 8:52 PM, Rich Hickey  wrote:

> On Apr 20, 2009, at 7:02 PM, Antony Blakey wrote:
> > On 21/04/2009, at 5:12 AM, Laurent PETIT wrote:
> >
> >> { :major 1 :minor 0 :release 0 :status :SNAPSHOT }
> >> then
> >> { :major 1 :minor 0 :release 0 :status :RC1 }  (release candidate 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
..- 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

[Daniel Jomphe]

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-.jar
  clojure-1.0.0--slim.jar
  clojure-1.0.0--javadoc.jar
  clojure-1.0.0--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-.jar
  clojure-1.0.1--slim.jar
  clojure-1.0.1--sources.jar

  clojure-1.1.0-.jar
  clojure-1.1.0--slim.jar
  clojure-1.1.0--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

[Laurent PETIT]

2009/4/21 AndrewC. :
>
> On Apr 21, 1:52 am, Rich Hickey  wrote:
>
>>
>> I'm unfamiliar with the POM version coordinate system - any hints?
>>
>> Rich
>
> 1 Pager on coordinates from the 'definitive guide'
>
> http://www.sonatype.com/books/maven-book/reference/simple-project-sect-maven-coordinates.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

[AndrewC.]

On Apr 21, 1:52 am, Rich Hickey  wrote:

>
> I'm unfamiliar with the POM version coordinate system - any hints?
>
> Rich

1 Pager on coordinates from the 'definitive guide'

http://www.sonatype.com/books/maven-book/reference/simple-project-sect-maven-coordinates.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

[Laurent PETIT]

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 :
>
> 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

[Mark Derricutt]

For a 1.0 release I'd love to see some support for JDK annotations
somehow, at both the gen-class and method level at least.

Mark

On Fri, Apr 17, 2009 at 4:53 AM, Rich Hickey  wrote:

> This is mostly about - does it work? Is it relatively free of bugs? Is
> it free of gaping holes in core 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 Jomphe]

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

[Antony Blakey]

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  
> ::: 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

[Antony Blakey]

On 21/04/2009, at 10:22 AM, Rich Hickey wrote:

> I'm unfamiliar with the POM version coordinate system - any hints?

My comment was in support of Laurent's proposal. I'm a relative maven  
newb, but this is my take:

POMs use the concept of a coordinate, which is  
::: to identify a particular  
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

[Rich Hickey]

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

[Daniel Jomphe]

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

[Antony Blakey]

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]

2009/4/20 Rich Hickey :

> If there is just a (def *version* {:major 1 :minor 0 :release 0})
>
> my questions are:
>
> What happens after release to keep subsequent interim versions from
> having the same 'version' as a release? Should we have a :status
> attribute that is :release for releases 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

[Laurent PETIT]

2009/4/20 Stuart Sierra 
>
> On Apr 20, 1:48 pm, Rich Hickey  wrote:
> > I imagine a (clojure-version) function returning:
> >
> > {:major 1 :minor 0 :release 0}
>
> I'd suggest calling :release something else, like :revision
> or :patch.  "release" sounds like a bigger number than major/minor.
> 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

[Phil Hagelberg]

Stuart Sierra  writes:

> On Apr 20, 1:48 pm, Rich Hickey  wrote:
>> I imagine a (clojure-version) function returning:
>>
>> {:major 1 :minor 0 :release 0}
>
> I'd suggest calling :release something else, like :revision
> or :patch.  "release" sounds like a bigger number than major/minor.
> Other 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

[Stuart Sierra]

On Apr 20, 1:48 pm, Rich Hickey  wrote:
> I imagine a (clojure-version) function returning:
>
> {:major 1 :minor 0 :release 0}

I'd suggest calling :release something else, like :revision
or :patch.  "release" sounds like a bigger number than major/minor.
Other than that, makes sense to me.

Maybe a ns flag like :clojure-version could indicate what Clojure
version a lib was developed for.  I'm assuming this will be used only
for information/warning purposes, NOT a hard constraint that prevents
the lib from being loaded on any other version.

-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

[Phil Hagelberg]

Rich Hickey  writes:

> If there is just a (def *version* {:major 1 :minor 0 :release 0})
>
> my questions are:
>
> What happens after release to keep subsequent interim versions from
> having the same 'version' as a release? Should we have a :status
> attribute that is :release for releases and :interim for non?

I like how that sounds. Either that or having a :prerelease key that
maps to true in interim releases.

Additionally release candidates should have a :release-candidate key if
we end up going down that path.

-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

[Rich Hickey]

On Apr 17, 5:21 pm, Tom Faulhaber  wrote:
> Tom's 2 cents:
>
> I think Clojure is basically ready to go to 1.0. I like the idea of
> having a book about Clojure 1.0 go hand in hand with the release.
>
> While I agree that the library management problem is too hard for a
> 1.0 release (and also 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.

I'd like some proposals for doing the version numbers.

I imagine a (clojure-version) function returning:

{:major 1 :minor 0 :release 0}

or something. We've had some prior discussions about how to do the svn
rev with no conclusion - most things seemed incredibly hackish, didn't
work for people building with different tools or from a git mirror
etc.

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?

I'd like to move forward on 1.0 with what we have now, and take the
most pressing wish list items raised in this discussion under
consideration for 1.1.

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

[Vincent Foley]

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  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

[Jeff Heon]

On Apr 17, 2:47 pm, revoltingdevelopment

 wrote:
> Aside from that, I think you are right about the psychology of
> language adoption and book-buying.  Declaring 1.0 to coincide with the
> content and publication date of Stuart's book is just an excellent
> idea, regardless of all the other issues 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

[Jeff Heon]

On Apr 17, 2:47 pm, revoltingdevelopment
 wrote:
> Aside from that, I think you are right about the psychology of
> language adoption and book-buying.  Declaring 1.0 to coincide with the
> content and publication date of Stuart's book is just an excellent
> idea, regardless of all the other issues 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

[Tom Faulhaber]

On Apr 18, 3:15 am, John Newman  wrote:
> > I do not agree with John Newman that the Java standard library
> > should be the Clojure standard library.
>
> I'm not saying that.  I'm saying that:
>

John, I misunderstood what you were trying to say. My apologies!

There seems to be some agreement 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

[Antony Blakey]

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

[Isak Hansen]

On Thu, Apr 16, 2009 at 6:53 PM, Rich Hickey  wrote:
>
> Feedback welcome,
>

1. I'd like to see a road map of sorts; plans for where Clojure will
be going with the next couple of releases.

2. Clojure-contrib -cleanup
 - Move the clojure test suite to clojure itself
 - Move 'worthy' libraries 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 .


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

[John Newman]

Well, perhaps if str-utils becomes the universal standard for string
operations, it would be rolled into Clojure come 2.0?

On Sat, Apr 18, 2009 at 2:58 PM, Konrad Hinsen wrote:

>
> On 18.04.2009, at 12:15, John Newman wrote:
>
> > 2) One way to maintain Clojure's flexibility would be if it were
> > 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

[Timothy Pratley]

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

[Konrad Hinsen]

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.


--~--~-~--~~~---~--~~
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

[John Newman]

> 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 wrote:

>
> Tom's 2 cents:
>
> I think Clojure is basically ready to go to 1.0. I like the idea of
> having a book about Clojure 1.0 go hand in hand with the release.
>
> While I agree that the library management problem is too hard for a
> 1.0 release (and also 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

[Konrad Hinsen]

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.

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

[Mark Reid]

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

[Antony Blakey]

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

[Paul Drummond]

2009/4/18 Laurent PETIT :
> [snip] at least Rich disagrees (and unanimity
> implies "all people", not even one let apart).
> And you can also count on me, Meikel Brandmeyer (author of VimClojure),
> maybe Paul Drummond (?) that pointed to python's decision to use Mercurial.

I have only used SVN 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

[Stuart Sierra]

On Apr 17, 9:21 am, Rich Hickey  wrote:
> A library management system seems like a tall order for a language
> 1.0. It is certainly an interesting and useful pursuit, but given the
> variety of approaches and opinions therein, it seems a bit out in
> front of us.

Yes.  I retract my request. :)  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

[Laurent PETIT]

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 

>
> 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

[Laurent PETIT]

2009/4/18 Laurent PETIT 

>
>
>
> Rich is the main maintainer of clojure source, just let him use the DVCS he
> wants. And really, it's not that difficult to checkout a working copy of
> svn, hack on it, and do a svn diff > mypatch.diff to send him when ready (so
> more complex management cases may well be easier with DVCs in the
> contributor side, of course) ...
>

 :%s/so/though

(you see Meikel, I know some Vim commands as well ;-)

--~--~-~--~~~---~--~~
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]

2009/4/18 Dan 

>
>
> On Fri, Apr 17, 2009 at 4:29 PM, Laurent PETIT wrote:
>
>> I guess there's really no perfect solution here :-(
>>
>> The question is :
>>
>> do you prefer to have some clojure users united against subversion, or
>> divided by Rich not having chosen their preferred DVCS (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.


A last word from me on the subject : unanimous is certainly not the right
term here, if you consider that 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.

But if 'unanimity' is not the right word, I admit that it seems that
'majority' would be.

Anyway, since I don't want to start or continue a pointless DVCS comparison
war, I won't even give any argument here in favor of mercurial or git.

Rich is the main maintainer of clojure source, just let him use the DVCS he
wants. And really, it's not that difficult to checkout a working copy of
svn, hack on it, and do a svn diff > mypatch.diff to send him when ready (so
more complex management cases may well be easier with DVCs in the
contributor side, of course) ...

Regards,

-- 
Laurent



>
> 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

[mikel]

On Apr 17, 8:31 pm, Antony Blakey  wrote:
> As a lurker, considering Clojure for a project, the thing that is  
> giving me pause isn't 1.0 per se, but the combination of a good  
> library mechanism and documentation. I have Stuart's book, and I agree  
> in the strongest possible terms that it should be a book explicitly  
> about a stable Clojure 1.0. The choice for me is between Scala and  
> Clojure, and the languages themselves are not a discriminator - it's  
> the environments around the languages that determine the outcome.
>
> 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.

It turns out that getting past these obstacles is quite easy, but, as
I say, you can't tell that when you're coming in cold. That suggests
that documentation is the solution.
--~--~-~--~~~---~--~~
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

[Antony Blakey]

As a lurker, considering Clojure for a project, the thing that is  
giving me pause isn't 1.0 per se, but the combination of a good  
library mechanism and documentation. I have Stuart's book, and I agree  
in the strongest possible terms that it should be a book explicitly  
about a stable Clojure 1.0. The choice for me is between Scala and  
Clojure, and the languages themselves are not a discriminator - it's  
the environments around the languages that determine the outcome.

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.

Please don't under-estimate the extent to which good documentation, an  
obvious and clean code base (which clojure-contrib isn't) and a  
documented story for packaging and managing extensions/contributions,  
gives the impression of quality, at least with respect to the kind of  
'quality' that comforts and convinces arms-length users. The website  
is quite good in some of those respects for clojure core.

Also +1 for moving to git and github - in my experience it motivates  
contributions/contributors because it is such a low-barrier platform  
for collaborative/experimentation.

Antony Blakey
-
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The ultimate measure of a man is not where he stands in moments of  
comfort and convenience, but where he stands at times of challenge and  
controversy.
   -- Martin Luther King



--~--~-~--~~~---~--~~
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

[rzeze...@gmail.com]

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

[Dan]

On Fri, Apr 17, 2009 at 4:29 PM, Laurent PETIT wrote:

> I guess there's really no perfect solution here :-(
>
> The question is :
>
> do you prefer to have some clojure users united against subversion, or
> divided by Rich not having chosen their preferred DVCS (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

[Luke VanderHart]

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  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 
>
>
>
> > 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  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

[Paul Drummond]

2009/4/17 Tom Faulhaber :
> While I agree that "what is clojure.contrib?" is a pretty big issue, I
> think we could leave it a little fuzzy for a while longer. One thing
> we should probably do is do a real comparison of how we stack up
> against python's "batteries included" model and see how we 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

[Paul Drummond]

2009/4/17 Laurent PETIT :
> do you prefer to have some clojure users united against subversion, or
> divided by Rich not having chosen their preferred DVCS (Mercurial users vs
> Git users, not sure whether clojure needs those kinds of nonsense internal
> wars in the community )

I agree the 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

[Tom Faulhaber]

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

[Mark Engelberg]

On Fri, Apr 17, 2009 at 6:21 AM, Rich Hickey  wrote:
> Overall, I'm getting feature requests (more change!) and not a strong
> drive for 1.0 stability. If you feel otherwise, please speak up.
> Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> users wary of working from 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

[Laurent PETIT]

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 

>
> 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  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

[mifrai]

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  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

[Cosmin Stejerean]

On Thu, Apr 16, 2009 at 11:53 AM, Rich Hickey  wrote:

[...]

>
> - Development process stability
>
> Currently all new work (fixes and enhancements) occurs in trunk.
> There's no way to get fixes without also getting enhancements. I think
> this is the major missing piece in offering stable 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

[mikel]

On Apr 17, 8:21 am, Rich Hickey  wrote:
> Thanks all for the feedback. One impression I get is that it seems the
> existing community is getting along ok on trunk, so perhaps we also
> need to consider those not yet using Clojure, possibly even because of
> a lack of 1.0.
>
> I joked about book 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

[revoltingdevelopment]

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

[Luke VanderHart]

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  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

[Daniel Jomphe]

> 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

[John Newman]

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  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

[Matt Revelle]

On Apr 17, 9:21 am, Rich Hickey  wrote:
*snip*
>Git is not going to happen any time soon, great as it may
> be, given the current lack of infrastructure (google code) and tools
> support. Is there some respect in which this impacts the core? It
> would seem dangerous to marry any single approach 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

[Stuart Halloway]

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

[Paul Stadig]

On Fri, Apr 17, 2009 at 9:21 AM, Rich Hickey  wrote:

> 
>
> As for tests, there are tests in:
>
>
> http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src/clojure/contrib/test_clojure
>
> Anyone who wants more tests can contribute them.
>

I think what would be useful, though, is to 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

[Jeff Heon]

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

[Luc Prefontaine]

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" i

Re: The Path to 1.0

[Ozzi Lee]

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

[e]

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  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

[Rich Hickey]

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

[Paul Drummond]

2009/4/16 Rich Hickey :
> What does 1.0 mean to you?

I just wanted to give some thoughts on what I think are the main
points coming from this discussion.  It seems like most agree that
"Clojure the language" is ready for a 1.0 release (and all that comes
with it).  The main issues are A) choice 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
-~--~~~~--~~--~--~---