Release.Next Version Number

[Christopher Redinger]

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=en&formkey=dE92bEdzMmpVOURDNUVHOWpaVXVhU3c6MQ#gid=0

Thanks!

[1] http://dev.clojure.org/display/design/Release.Next+Planning

--

Christopher Redinger

http://clojure.com

[Lärry]

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

[David Jacobs]

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

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[Saul Hazledine]

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

[David Jacobs]

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 "SNAPSHOT"s 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

[Aaron Bedra]

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

[Lee Spector]

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

[Glen Stampoultzis]

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

[Chas Emerick]

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 "SNAPSHOT"s 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

[David Jacobs]

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

[Brian Marick]

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

[Ken Wesson]

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?

[Laurent PETIT]

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

[semperos]

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.

[Steve Miner]

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

[Shantanu Kumar]

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

[David]

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.

[Dennis Crenshaw]

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?

[David]

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

[Dennis Crenshaw]

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.

[Chas Emerick]

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

[Kevin Downey]

you mean inc

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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?

[Armando Blancas]

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

[Brenton]

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=en&f...

[Brian Marick]

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.

[Christopher Redinger]

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=en&formkey=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."