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
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 l
> 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 Goog
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
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 con
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 langu
you mean inc
On Thu, Feb 24, 2011 at 8:45 AM, 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 constitut
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 ma
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 t
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
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 wrote:
> Another vote for semantic versioning. I agree that the "claim
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 chang
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
2011/2/24 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-h
On Wed, Feb 23, 2011 at 9:23 PM, Brian Marick 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 doabl
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
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
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
>> - 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
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 sugges
>
> 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 ju
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'
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
wrote:
> - definitive, simple, integrated package management
Leiningen and Cake?
> - a better REPL experience out of the box (esp. Jline support)
Sl
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, simp
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
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 t
26 matches
Mail list logo
