Re: Release.Next Version Number
I'm going to leave the poll up for one more week for those interested in casting a vote. https://spreadsheets.google.com/a/thinkrelevance.com/viewform?hl=enformkey=dE92bEdzMmpVOURDNUVHOWpaVXVhU3c6MQ#gid=0 Just to be clear, this is about capturing a strong objection to calling the next version 1.3. If you are in the camp of not caring what the next version number is, then you do not have a strong objection. I.e. you are not morally opposed. On Feb 22, 2011, at 9:27 PM, Christopher Redinger wrote: As you can see on the Release.Next Planning page [1], there is an open question about whether or not the next version of Clojure should be 1.3 or 2.0. The issue at hand is that we are introducing backwards incompatible API changes. Not looking to start a debate at this point, but just taking a temperature reading from the community. If you care about what the next version number of Clojure is - could you please cast a vote in the poll here: https://spreadsheets.google.com/a/thinkrelevance.com/viewform?hl=enformkey=dE92bEdzMmpVOURDNUVHOWpaVXVhU3c6MQ#gid=0 Thanks! [1] http://dev.clojure.org/display/design/Release.Next+Planning -- Christopher Redinger http://clojure.com -- Christopher Redinger http://clojure.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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
2011/2/24 Brian Marick mar...@exampler.com On Feb 23, 2011, at 3:06 PM, David Jacobs wrote: Thanks for the suggestions. I should say that I was only giving you my impression of using Clojure re: it's version number. I'm not saying any of the things I listed are not doable, just that they feel very ad-hoc and not quite ready for a 2.0. I agree. My gut tells me 2.0 implies promises about the ecosystem and ease-of-adoption. Clojure 2.0 would be overpromising. Better to underpromise and overdeliver, as they say. Well, day after day, I'm leaning more towards semantics versioning. Because, heh, given the dilemnas that everybody spotted in each solution, why not just choose the pragmatic and semantic-full versioning scheme ? Do people really relate the numbers in Windows 7 and MacOS 10, for example ? C'mon ... -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
Another vote for semantic versioning. I agree that the claim to 2.0 comes with some expectations about environment and overall development experience, but I think that *backwards incompatible changes* deserve a major version bump, to keep heads straight and make it clear to newcomers where the lines are drawn. If we don't make the switch now, at which future set of breaking changes will we decide it's time to call it 2.0? We'd basically have to create our own criteria and have the Clojure flavored semantic versioning scheme, which I think would be more arbitrary and harder for folks to follow. -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
The choice boils down to whether or not you want to follow Semantic Versioning [1]. Apache (APR) [2], Eclipse [3], and OSGi [4] all seem to have equivalent policies. Personally, I think it's a perfectly logical approach to increment the major version number for any backwards incompatible change. Python officially has a more relaxed interpretation [5]. My understanding is that in practice the Python community was very concerned about backwards compatibility among the late 2.x releases because 3.0 was going to introduce big changes. Python versions are numbered A.B.C or A.B. A is the major version number – it is only incremented for really major changes in the language. B is the minor version number, incremented for less earth-shattering changes. C is the micro-level – it is incremented for each bugfix release. The Wikipedia article on software versioning [6] covers some other concerns such as marketing. I guess that takes into account the idea that 2.0 should be a major improvement. As I said, I personally like the concept of semantic versioning. If Rich wants to do something else, I can live with an incompatible 1.3. In any case, it would be useful for the Clojure Core team to document the Clojure version policy. [1] http://semver.org [2] http://apr.apache.org/versioning.html [3] http://wiki.eclipse.org/index.php/Version_Numbering [4] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf [5] http://docs.python.org/faq/general.html#how-does-the-python-version-numbering-scheme-work [6] 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
I have noticed some projects go to an x.5 release when they are half- ready to move to (inc x).0 -- in this case which would be 1.5 instead of 1.3 or 2.0 version. Just a thought. Regards, Shantanu On Feb 24, 7:56 pm, semperos daniel.l.grego...@gmail.com wrote: Another vote for semantic versioning. I agree that the claim to 2.0 comes with some expectations about environment and overall development experience, but I think that *backwards incompatible changes* deserve a major version bump, to keep heads straight and make it clear to newcomers where the lines are drawn. If we don't make the switch now, at which future set of breaking changes will we decide it's time to call it 2.0? We'd basically have to create our own criteria and have the Clojure flavored semantic versioning scheme, which I think would be more arbitrary and harder for folks to follow. -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
On Thu, 2011-02-24 at 11:33 -0500, Steve Miner wrote: The choice boils down to whether or not you want to follow Semantic Versioning [1]. Apache (APR) [2], Eclipse [3], and OSGi [4] all seem to have equivalent policies. Personally, I think it's a perfectly logical approach to increment the major version number for any backwards incompatible change. Python officially has a more relaxed interpretation [5]. My understanding is that in practice the Python community was very concerned about backwards compatibility among the late 2.x releases because 3.0 was going to introduce big changes. Python versions are numbered A.B.C or A.B. A is the major version number – it is only incremented for really major changes in the language. B is the minor version number, incremented for less earth-shattering changes. C is the micro-level – it is incremented for each bugfix release. The Wikipedia article on software versioning [6] covers some other concerns such as marketing. I guess that takes into account the idea that 2.0 should be a major improvement. As I said, I personally like the concept of semantic versioning. If Rich wants to do something else, I can live with an incompatible 1.3. In any case, it would be useful for the Clojure Core team to document the Clojure version policy. [1] http://semver.org [2] http://apr.apache.org/versioning.html [3] http://wiki.eclipse.org/index.php/Version_Numbering [4] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf [5] http://docs.python.org/faq/general.html#how-does-the-python-version-numbering-scheme-work [6] http://en.wikipedia.org/wiki/Software_versioning I agree. One thing we should keep in mind is that if we're going to follow semantic versioning, we should not plan *any* backwards-incompatible changes in the near future. In other words, after 2.0, we should be done changing the language for a while, or we'll risk bumping major versions on every release. -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable to make a standard out of it. To quote Peter Drucker, What gets measured gets managed. Are there any solid examples of languages that would constitute a good canonical spectrum for ecosystem versions and why? It seems like if the ecosystem surrounding a language is another concern in the semantic versioning equation that can't be sufficiently be expressed by the existing scheme, there should be a another digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0 or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may mean, ecosystem surrounding it.) My points may also be a moot point, since it seems to make this SemVer compatible we might have to call it SemVer 1.1.0, or 2.0 depending on how people thought the extra digit(s) would affect the compatibility with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?) All this being said, I like the idea of semantic versioning and I wish more languages/software at least attempted some sort of version number scheme transparency. #(+ 1 %) to semantic versioning. TL;DR Can an ecosystem be properly versioned? Can that version be cleanly expressed by the current SemVer scheme? -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
Part of my underlying concern is one of branding and not directly based on concerns about measuring and/or quantifying the quality of an ecosystem. I fully recognize that we could call the next iteration of Clojure 2.0 and would be well within our rights. My point has been that calling it 2.0 may give people the impression that developing in the language is seamless and well-polished. When they find out that it's not, Clojure may experience some backlash. (What's more, if Clojure wants to continue adding backwards-incompatible features at the same rate that it is now, it would not be advisable to bump the major version just yet.) That said, I don't have a real problem saying the language itself is 2.0-worthy. David On Thu, 2011-02-24 at 11:45 -0500, Dennis Crenshaw wrote: What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable to make a standard out of it. To quote Peter Drucker, What gets measured gets managed. Are there any solid examples of languages that would constitute a good canonical spectrum for ecosystem versions and why? It seems like if the ecosystem surrounding a language is another concern in the semantic versioning equation that can't be sufficiently be expressed by the existing scheme, there should be a another digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0 or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may mean, ecosystem surrounding it.) My points may also be a moot point, since it seems to make this SemVer compatible we might have to call it SemVer 1.1.0, or 2.0 depending on how people thought the extra digit(s) would affect the compatibility with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?) All this being said, I like the idea of semantic versioning and I wish more languages/software at least attempted some sort of version number scheme transparency. #(+ 1 %) to semantic versioning. TL;DR Can an ecosystem be properly versioned? Can that version be cleanly expressed by the current SemVer scheme? -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
you mean inc On Thu, Feb 24, 2011 at 8:45 AM, Dennis Crenshaw crensha...@gmail.com wrote: What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable to make a standard out of it. To quote Peter Drucker, What gets measured gets managed. Are there any solid examples of languages that would constitute a good canonical spectrum for ecosystem versions and why? It seems like if the ecosystem surrounding a language is another concern in the semantic versioning equation that can't be sufficiently be expressed by the existing scheme, there should be a another digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0 or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may mean, ecosystem surrounding it.) My points may also be a moot point, since it seems to make this SemVer compatible we might have to call it SemVer 1.1.0, or 2.0 depending on how people thought the extra digit(s) would affect the compatibility with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?) All this being said, I like the idea of semantic versioning and I wish more languages/software at least attempted some sort of version number scheme transparency. #(+ 1 %) to semantic versioning. TL;DR Can an ecosystem be properly versioned? Can that version be cleanly expressed by the current SemVer scheme? -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
Inc is probably a better way to say that, yeah. I also agree with David that 2.0 has a popular connotation of shiny-ness that came with the whole infamous Web 2.0 branding phenomenon. I am now at conflict internally, because I'd like to see Clojure widely adopted, but I like the idea of the language having the agility to do radical things to make itself better in a way that Java no longer posses. So 1.3 still has its advantages. Clojure always has the choice to stay the transition to semantic versioning until Rich feels that it's at a place that semantic versioning makes sense. I believe I've thought myself in a circle and need some hammock time on this. -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
I think we can all agree that the world would be a better place if every project strictly followed semantic versioning and if people interpreted version numbers accordingly. It would be a triumph of science over mysticism. But we know that people don't do this and that is why we are having this conversation. For some languages, taking into account what people are used to doing is an important concern (Java, C++). But I don't think that is Clojure's philosophy. Come on people, it's a Lisp. It would have never been a Lisp if Rich cared what the gut reaction of the masses would be. The core philosophy of Clojure is to do it right (even if that is not popular) and then convince people as to why this is the right way to do things. Clojure isn't a Trojan horse, it's a beacon of hope. Let's continue that tradition and not do something based on gut reactions. Let's do it right and call it the backward incompatible version 2.0 that it is. Maybe it will inspire other projects to do the same. Brenton On Feb 22, 6:27 pm, Christopher Redinger ch...@thinkrelevance.com wrote: As you can see on the Release.Next Planning page [1], there is an open question about whether or not the next version of Clojure should be 1.3 or 2.0. The issue at hand is that we are introducing backwards incompatible API changes. Not looking to start a debate at this point, but just taking a temperature reading from the community. If you care about what the next version number of Clojure is - could you please cast a vote in the poll here: https://spreadsheets.google.com/a/thinkrelevance.com/viewform?hl=enf... Thanks! [1]http://dev.clojure.org/display/design/Release.Next+Planning -- Christopher Redingerhttp://clojure.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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
On Feb 24, 2011, at 3:09 PM, David wrote: I fully recognize that we could call the next iteration of Clojure 2.0 and would be well within our rights. My point has been that calling it 2.0 may give people the impression that developing in the language is seamless and well-polished. When they find out that it's not, Clojure may experience some backlash. Without commenting on the validity of the above at all, I seem to recall that the application of the 1.0 version label prompted the same sort of concerns. - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
Without commenting on the validity of the above at all, I seem to recall that the application of the 1.0 version label prompted the same sort of concerns. You're right. No point in commenting on this whole silly thread. -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
On Feb 23, 2011, at 8:36 PM, Ken Wesson wrote: But 1.3 may overpromise and underdeliver backward compatibility. It depends, I suppose, on whether people who are already using Clojure 1.2 will blindly upgrade to 1.3/2.0 without having read anything that will warn them what to expect. I like semantic versioning myself, but I think considerations are different for peripheral libraries like mine than they are for the foundational core of the whole shebang. - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Author of /Ring/ (forthcoming; sample: http://exampler.com/tmp/ring.pdf) www.exampler.com, www.exampler.com/blog, www.twitter.com/marick -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
Gang - I'm still in the playing stage with the language. I'm exploring Clojure and prototyping ideas for future directions. The language is very expressive and its community is quite supportive. One thing the environment lacks is a good, current book for beginners. Oh, there are a couple of good books out there. The problem is that the books are out-dated, because they are based on versions 1.0 or 1.1. This means that the language needs to be rich enough and we need to settle on a standard platform and stick with it long enough for the writers to catch up. (This doesn't mean stagnation. Please don't let Clojure 2.0 become the end of the line - like Java 2.) Version 2.0 of any product usually signifies a coming-of-age, where it is ready for prime-time, ready to become THE solution for a certain set of problems. If we believe that the next release of Clojure will be the platform for the next stage of growth, then I'm all for calling it 2.0. If it's just a stepping-stone, call it 1.3. The other thing the environment needs is a killer app. But that's a different thread... - Larry -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
If we want to practice semantic versioning[0] and the next iteration is introducing backwards-incompatible changes, we should go with 2.0. However, I have my reservations. Clojure itself feels solid to code with, but the *ecosystem* doesn't feel very 2.0. For that it would need: - definitive, simple, integrated package management - a better REPL experience out of the box (esp. Jline support) - a simpler, more useful stack trace - better commandline integration - abstracting away Java concepts like excessive hierarchies for package definitions (src/com/mycompany/wow/this/is/getting/long/my-library.clj) - better discovery for existing, well-tested libraries. [0] http://semver.org/ Those, for me, are the rough edges of Clojure, the ones that aggravate me at times. They don't have as much to do with the language itself as with the ecosystem, so I'm okay calling a new version of the language 2.0. Just my $0.02. David Jacobs On Wed, Feb 23, 2011 at 11:18 AM, Lärry ki6...@gmail.com wrote: Gang - I'm still in the playing stage with the language. I'm exploring Clojure and prototyping ideas for future directions. The language is very expressive and its community is quite supportive. One thing the environment lacks is a good, current book for beginners. Oh, there are a couple of good books out there. The problem is that the books are out-dated, because they are based on versions 1.0 or 1.1. This means that the language needs to be rich enough and we need to settle on a standard platform and stick with it long enough for the writers to catch up. (This doesn't mean stagnation. Please don't let Clojure 2.0 become the end of the line - like Java 2.) Version 2.0 of any product usually signifies a coming-of-age, where it is ready for prime-time, ready to become THE solution for a certain set of problems. If we believe that the next release of Clojure will be the platform for the next stage of growth, then I'm all for calling it 2.0. If it's just a stepping-stone, call it 1.3. The other thing the environment needs is a killer app. But that's a different thread... - Larry -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
Below are suggestions to the shortcomings you mention. I'm genuinely interested in how they don't meet your needs. On Feb 23, 8:42 pm, David Jacobs develo...@allthingsprogress.com wrote: - definitive, simple, integrated package management Leiningen and Cake? - a better REPL experience out of the box (esp. Jline support) Slime/Emacs? I only use the REPL in very rare cases and aren't bothered by a lack of JLine. - a simpler, more useful stack trace Slime? - better commandline integration https://github.com/gar3thjon3s/clargon - abstracting away Java concepts like excessive hierarchies for package definitions (src/com/mycompany/wow/this/is/getting/long/my-library.clj) You don't have to use this convention. Personally I keep things shallow. - better discovery for existing, well-tested libraries. You can search on http://clojars.org/. This works well for me. However, the key to well tested libraries is having people give feedback if a library breaks or is badly documented or doesn't meet their needs. Saul -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
Hi Saul, Thanks for the suggestions. I should say that I was only giving you my impression of using Clojure re: it's version number. I'm not saying any of the things I listed are not doable, just that they feel very ad-hoc and not quite ready for a 2.0. I come from the Ruby world, and Ruby isn't even a 2.0, so my perspective is definitely colored. - definitive, simple, integrated package management Leiningen and Cake? I use leiningen and cljr for package management, depending on whether I'm working on a discrete project or on a script/quick hack/toy program. These tools are great, and I don't want to diminish the amount of effort that's gone into them. However, the whole process of getting package management working is a barrier to entry to Clojure. Getting package management up and running requires too many steps. I think that Clojure should come with a default executable that can take care of package management and start a REPL (loading all global packages into the classpath). Integrating leiningen into Clojure packages would give this definitive experience that new users are looking for when they try to get up and running. - a better REPL experience out of the box (esp. Jline support) Slime/Emacs? I only use the REPL in very rare cases and aren't bothered by a lack of JLine. - a simpler, more useful stack trace Slime? Three problems with the REPL: 1. The standard way Clojure tells me to get a REPL is using the java command. This makes Clojure not feel like a first-class language. 2. Once I do get a REPL, either through the java or lein or cljr commands, it has no indentation or Jline support. It feels messy. 3. I use Vim, so Emacs/Slime isn't really something I want to do. (And I don't want to have to use a specific editor in order to use the language of my choice.) - better commandline integration https://github.com/gar3thjon3s/clargon I'll give this a look. In general, I think we need a way to write Clojure scripts so that they are directly executable (perhaps via a shebang directive at the top of our script). - abstracting away Java concepts like excessive hierarchies for package definitions (src/com/mycompany/wow/this/is/getting/long/my-library.clj) You don't have to use this convention. Personally I keep things shallow. You're right, but a lot of people do (even clojure.contrib does), which makes browsing Clojure source code feel rough. - better discovery for existing, well-tested libraries. You can search on http://clojars.org/. This works well for me. However, the key to well tested libraries is having people give feedback if a library breaks or is badly documented or doesn't meet their needs. To me, Clojars is not the most discoverable interface in the world, though I do appreciate that it exists. It doesn't have download counts or any other sort of quality indicator. What's more, some entries are domain-qualified and others aren't, and it's hard to know exactly what I'm getting when I install any package from Clojars. Side question (also relating to the ecosystem feeling rough), what's with all the SNAPSHOTs on Clojars? As I say, I really enjoy coding in Clojure, but the process surrounding coding is not always very polished. I see too much Java and not quite enough integration to think of it as a 2.0 yet, though I do think we can get there. I'm open-minded about this take, though. Maybe I just don't have a solid enough setup on my machine yet. (But should it really take that much effort?) David -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
I come from the Ruby world, and Ruby isn't even a 2.0, so my perspective is definitely colored. It seems to me like (most) of the things you are talking about are not core language specific things. In particular for package management Ruby uses Rubygems which is a separate project, and just recently Bundler for dependency management. To me these things have no impact on the language and shouldn't keep the language from moving forward in a version numbering sense. I do agree that they should mature though. Three problems with the REPL: 1. The standard way Clojure tells me to get a REPL is using the java command. This makes Clojure not feel like a first-class language. Agreed, there is a ticket for this in JIRA. 2. Once I do get a REPL, either through the java or lein or cljr commands, it has no indentation or Jline support. It feels messy. From what I have seen most people aren't using the bare REPL or lein repl, but the experience could be better. 3. I use Vim, so Emacs/Slime isn't really something I want to do. (And I don't want to have to use a specific editor in order to use the language of my choice.) Sorry if you are already aware of this, but there is a vim plugin for slime that I have heard good things about. - better discovery for existing, well-tested libraries. Well tested is completely a matter of opinion and is another one of those things that doesn't seem like a reason to hold back a 2.0. As I say, I really enjoy coding in Clojure, but the process surrounding coding is not always very polished. I see too much Java and not quite enough integration to think of it as a 2.0 yet, though I do think we can get there. I can completely understand what you mean after coming from the Ruby world where there has been a ton of effort spent on making the development experience better. I think we can take a lot away from what Ruby has done. Two of the Clojure/core team members (Stuart Halloway and me) also came from Ruby and spent quite a bit of time helping make it better while we were there. I do want to make sure that the things we think about when calling a release 2.0 factor more into what has changed since the last release. This would be both how much has changed, and how many breaking changes have occurred. I don't want to dismiss what you have brought up though because I think they are all really important for the adoption of the language going forward. Cheers. Aaron -- Clojure/core http://clojure.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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
I don't have a strong opinion about the version number but I want to say that David's critiques of the state of the ecosystem all ring true to me. FWIW (and I offer this only because Saul is genuinely interested in how they don't meet your needs :-) here are my own responses to David's suggestions/questions about Saul's critiques: On Feb 23, 2011, at 2:58 PM, Saul Hazledine wrote: Below are suggestions to the shortcomings you mention. I'm genuinely interested in how they don't meet your needs. On Feb 23, 8:42 pm, David Jacobs develo...@allthingsprogress.com wrote: - definitive, simple, integrated package management Leiningen and Cake? Both seem great but neither plays nice with an editor/IDE/workflow that works well for me. Eclipse/CCW is my current favorite and while there are ways to use lein in conjunction with Eclipse projects they are seriously non-intuitive. I was initially very excited about TextMate/cake but some basic things failed to work and my posted issue on the textmate-clojure github site got no reply so I cooled on this and went back to Eclipse/CCW. I'm a long-time emacs user but the installation/configuration issues are infuriating, especially in a teaching context (which is important for me), as are some of the decades-old UI conventions. - a better REPL experience out of the box (esp. Jline support) Slime/Emacs? I only use the REPL in very rare cases and aren't bothered by a lack of JLine. See above. I'm looking for a non-emacs solution (or maybe I'd be happy with a fail-proof simple Aquamacs-for-clojure single-click-download+installer). I use REPLs all the time and want them to have basic features like parentheses matching, language-aware indentation, and the ability to scroll through history. - a simpler, more useful stack trace Slime? See above. - better commandline integration https://github.com/gar3thjon3s/clargon Not actually a concern of mine. - abstracting away Java concepts like excessive hierarchies for package definitions (src/com/mycompany/wow/this/is/getting/long/my-library.clj) You don't have to use this convention. Personally I keep things shallow. Some tools force or strongly encourage such conventions (and they vary among tools). If I recall correctly NetBeans/Enclojure uses fairly deep hierarchies. Eclipse's are shallower, I think, and the default for new projects in cake is somewhere in between. I gather that keeping things completely flat is somehow impossible or bad in the Java ecosystem in general, but the variation among all of the popular tools is indeed bothersome. - better discovery for existing, well-tested libraries. You can search on http://clojars.org/. This works well for me. However, the key to well tested libraries is having people give feedback if a library breaks or is badly documented or doesn't meet their needs. I'm still surprised sometimes even by things that are in core or contrib that I hadn't seen previously. Clojure.org doesn't help much with this, in my experience. I've found some of the newer documentation sites (like http://clojuredocs.org/) to be quite good but again this is sort of scattered, with a bunch of things of different levels of completeness and quality and not a lot of guidance to the newcomer about where to go to get oriented. If this situation could be firmed up for core+contrib, and then expanded to other libraries, then that would be fantastic. Just my e cents or so. -Lee -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
- better discovery for existing, well-tested libraries. You can search on http://clojars.org/. This works well for me. However, the key to well tested libraries is having people give feedback if a library breaks or is badly documented or doesn't meet their needs. I'm currently working on something that might help fill this space. It's not yet complete and shouldn't be used except for testing at this stage. http://clojure-libraries.appspot.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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
On Feb 23, 2011, at 4:06 PM, David Jacobs wrote: - better discovery for existing, well-tested libraries. You can search on http://clojars.org/. This works well for me. However, the key to well tested libraries is having people give feedback if a library breaks or is badly documented or doesn't meet their needs. To me, Clojars is not the most discoverable interface in the world, though I do appreciate that it exists. It doesn't have download counts or any other sort of quality indicator. What's more, some entries are domain-qualified and others aren't, and it's hard to know exactly what I'm getting when I install any package from Clojars. I've never quite understood the criticism that it's difficult to find Clojure libraries -- perhaps because I came primarily from the Java and Python worlds, both of which share the same library-discovery mechanism (i.e. Google). That said, of course it'd be great to have a top-notch directory (and it looks like various people are working on that). In any case, this isn't relevant to the language's versioning. Side question (also relating to the ecosystem feeling rough), what's with all the SNAPSHOTs on Clojars? Clojars provides only one repository, where both SNAPSHOTs and releases are deployed. AFAICT, few people understand what SNAPSHOT implies, and the importance of having sane releases (i.e. a non-SNAPSHOT version as well as having no transitive SNAPSHOT-versioned dependencies). It's an unfortunate state of affairs. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
I don't really understand why snapshots should be in Clojars at all, yeah. It seems to me like CPAN, RubyGems, etc., encourage versioned software and not snapshots, because they're going for non-volatile, stable packages. I think Clojars should, too. You're right, that's neither here nor there re: 2.0, though, so I guess if we want to talk about that, we can take it to another thread. David On Wed, Feb 23, 2011 at 7:01 PM, Chas Emerick cemer...@snowtide.com wrote: On Feb 23, 2011, at 4:06 PM, David Jacobs wrote: - better discovery for existing, well-tested libraries. You can search on http://clojars.org/. This works well for me. However, the key to well tested libraries is having people give feedback if a library breaks or is badly documented or doesn't meet their needs. To me, Clojars is not the most discoverable interface in the world, though I do appreciate that it exists. It doesn't have download counts or any other sort of quality indicator. What's more, some entries are domain-qualified and others aren't, and it's hard to know exactly what I'm getting when I install any package from Clojars. I've never quite understood the criticism that it's difficult to find Clojure libraries -- perhaps because I came primarily from the Java and Python worlds, both of which share the same library-discovery mechanism (i.e. Google). That said, of course it'd be great to have a top-notch directory (and it looks like various people are working on that). In any case, this isn't relevant to the language's versioning. Side question (also relating to the ecosystem feeling rough), what's with all the SNAPSHOTs on Clojars? Clojars provides only one repository, where both SNAPSHOTs and releases are deployed. AFAICT, few people understand what SNAPSHOT implies, and the importance of having sane releases (i.e. a non-SNAPSHOT version as well as having no transitive SNAPSHOT-versioned dependencies). It's an unfortunate state of affairs. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. 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 -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
On Feb 23, 2011, at 3:06 PM, David Jacobs wrote: Thanks for the suggestions. I should say that I was only giving you my impression of using Clojure re: it's version number. I'm not saying any of the things I listed are not doable, just that they feel very ad-hoc and not quite ready for a 2.0. I agree. My gut tells me 2.0 implies promises about the ecosystem and ease-of-adoption. Clojure 2.0 would be overpromising. Better to underpromise and overdeliver, as they say. - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Author of /Ring/ (forthcoming; sample: http://exampler.com/tmp/ring.pdf) www.exampler.com, www.exampler.com/blog, www.twitter.com/marick -- 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 Note that posts from new members are moderated - please be patient with your first post. 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: Release.Next Version Number
On Wed, Feb 23, 2011 at 9:23 PM, Brian Marick mar...@exampler.com wrote: On Feb 23, 2011, at 3:06 PM, David Jacobs wrote: Thanks for the suggestions. I should say that I was only giving you my impression of using Clojure re: it's version number. I'm not saying any of the things I listed are not doable, just that they feel very ad-hoc and not quite ready for a 2.0. I agree. My gut tells me 2.0 implies promises about the ecosystem and ease-of-adoption. Clojure 2.0 would be overpromising. Better to underpromise and overdeliver, as they say. But 1.3 may overpromise and underdeliver backward compatibility. How do you suggest we resolve this dilemma? -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Release.Next Version Number
As you can see on the Release.Next Planning page [1], there is an open question about whether or not the next version of Clojure should be 1.3 or 2.0. The issue at hand is that we are introducing backwards incompatible API changes. Not looking to start a debate at this point, but just taking a temperature reading from the community. If you care about what the next version number of Clojure is - could you please cast a vote in the poll here: https://spreadsheets.google.com/a/thinkrelevance.com/viewform?hl=enformkey=dE92bEdzMmpVOURDNUVHOWpaVXVhU3c6MQ#gid=0 Thanks! [1] http://dev.clojure.org/display/design/Release.Next+Planning -- Christopher Redinger http://clojure.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 Note that posts from new members are moderated - please be patient with your first post. 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
