The Path to 1.0
Rich Hickey
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
dysinger
unless ---- you use a non-linear source control like Git. (please
switch?) :)
Ok no flames please - but since we have switched to Git nearly 2 years
ago we have been blessed with it's abilities to keep a stable branch
"master" and a RC branch "next" going with the freedom to try anything
in the background (topic branches). Branching is easy, cheap and fun
and I create a branch for every new bugfix or feature.
It's a thing of beauty and I could never go back to SVN or CVS. I
would switch to Hg first (badomp bomp *ching*) :) Just my $0.02
dysinger
pull ClojureCLR and other stuff I don't want into my clone. It would
make it less "kitchen junk drawer".
Another benefit of being on Git is people can fork, fix and send you
pull requests (which you can accept or not at your discretion). It
just encourages easy fork/branch/collaborate.
Stuart Sierra
> What does 1.0 mean to you? Are we there yet? Any recommendations for
> the organization of the release branches, patch policy etc?
management system. As noted before, contrib is already getting
hairy. We have dozens of little libraries floating around on GitHub.
Having you, Rich, maintain the list of libraries on clojure.org is not
sustainable. We don't need a fully-realized CPAN/RubyGem but we need
something that can scale to a few hundred authors. Dependency
management and documentation markup are components of this.
-Stuart Sierra
e
e
Also a benefit of being on Git for contrib would mean I don't have to
pull ClojureCLR and other stuff I don't want into my clone. It would
make it less "kitchen junk drawer".
Another benefit of being on Git is people can fork, fix and send you
pull requests (which you can accept or not at your discretion). It
just encourages easy fork/branch/collaborate.
making the common case easy is important. I like good branching, too, for when you need it, but is it the common case, or does it fly in the face of what we are talking about here?
Dan
What does 1.0 mean to you? Are we there yet? Any recommendations for
the organization of the release branches, patch policy etc?
Ideally, since backward compatibility is a big selling point of Java, I'd like to be able to tell clojure I require say version 1.0 and get the 1.0 behaviour even if I'm running on a newer version. It would enable the language to grow while providing a nice compatibility layer. Unless that's too hard or there is ramifications I'm not seeing.
Raoul Duke
my view of Java's backward compatibility is that it is kind of a bunch
of hot air that restricts the ecosystem from being better. i vastly
prefer the fact that .net is willing to make real changes to get real
benefits.
sincerely.
$0.02
Chas Emerick
+1. I worry about the cpan/gem mention, though. We're still in the
java world w.r.t. build and packaging, which generally means using
something like ivy/maven/svn:externals/git-submodule/etc ahead of
one's build process, rather than using cpan/gem/easy_install/etc at
deployment time.
That said, I have no concrete suggestion, as we'll always separately
pull our projects' dependencies into whatever we happen to be using as
a dependency management repo (it's a bummer to not be able to run a
build if some third-party repo is down, etc).
Regarding documentation, I remember throwing around ideas in irc some
months ago about how to fold documentation from gen-class'ed libs into
a library's broader javadoc. That would be a huge boon to those using
clojure to build libraries that would be transparently usable by Java
developers.
- Chas
dysinger
needs to not ignore the 10s of thousands of libraries tucked away in
maven2 repos. Something like Ties w/ compile support would be cool.
Git submodules, SVN externals & Hg forrest won't work either because
everyone uses different source control (and sorry I am not switching
off git :P ).
Dan
my view of Java's backward compatibility is that it is kind of a bunch
of hot air that restricts the ecosystem from being better. i vastly
prefer the fact that .net is willing to make real changes to get real
benefits.
sincerely.
$0.02
I did not suggest the language and API should not change and remain forever compatible, only that if possible, instead of doing something like this:
(if (> *clojure-version* 1.0) (do-something) (do-something-else))
I could do something like:
(ns my-namespace (:clojure-version "1.0"))
and expect clojure to reroute through the old code and the old api.
Clojure would stay free to evolve. The question is whether or not the cost of maintaining the plumbings to require old APIs is worth the cost.
I am not really apt to judge what it involves so I'll wait for others to enlighten me.
If it's not worth the cost, I'd be happy with a "works-perfectly, warns, gone" deprecation policy.
Mark Addleman
around versioning and classpath management in the standard Java
world. As for development versioning issues, Maven is the de facto
standard.
While I certainly don't think that Clojure 1.0 should have any
dependency on OSGi, I'd personally like to see the libraries evolve
that direction with some library API support. The API support would
likely parallel the OSGi jar manifest declarations. That API could
serve both as build time code to generate the static manifest files
necessary to play in an OSGi container as well as runtime declarations
of services and dynamic dependencies.
Howard Lewis Ship
>
> 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.
Clojure x.y.z
z increments when a release changes functionality but not (public) APIs.
y increments when a release adds new public APIs.
x increments when public APIs change in a non-compatible way.
People should have the expectation that an upgrade from 1.0.2 to 1.0.3
should be painless (and you should be able
to back down from 1.0.3 to 1.0.2 without any compilation errors). An
upgrade from 1.0.3 to 1.1.0 may not be reversable
(if you start using new APIs in 1.1.0, your code won't compile is you
revert to 1.0.3).
However, this is very hard to achieve in practice (so far we haven't
pulled this off for Tapestry);
just knowing how a particular change affects the y or z digit takes
experience. In addition,
there's a drive from end users who want pre-compiled snapshots of
versions short of a fully endorsed release. That's one of the reasons
I've put some effort into the Clojure nightly builds and Maven
repository: to allow people to track the latest without building it
themselves,
or asking Rich to make more frequent releases.
Clojure has an advantage here that functions, rather than objects, are
extremely fine grained. In addition, macros and multimethods allow
API compatibility to be maintained even as new features are added.
Finally, my experience with final releases is that they rarely are.
Drawing a line in the sand and saying "this is the 1.0 release"
usually results
in a frantic batch of patch releases. Instead, release a candidate,
say "1.0.1". If you find bugs, release a new "1.0.2". When bugs stop
being deal-busters,
announce that "1.0.2" is the GA release. In other words, let a release
prove itself before being anointed the final release. Having a fixed
release version
number is no different than having a fixed release date: those are
impositions by marketing, not an engineering decision.
I think there is a definite need, however, to ** get tests into
clojure-lang **. The tests will be the best way to determine how a
change affects
compatibility. Regressions are very hard to predict, and I don't trust
myself to identify which changes will break client code, and which
will not ... short of having a test
to represent client code. The lack of tests and the sorry state of
Java code documentation are daunting to many, including myself. Rich
is obviously brilliant, but any successful
project has to scale beyond its creator. The lack of tests and
documentation borders on arrogance.
>
> 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
>
> >
>
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
Michael Wood
[...]
> That said, I have no concrete suggestion, as we'll always separately
> pull our projects' dependencies into whatever we happen to be using as
> a dependency management repo (it's a bummer to not be able to run a
> build if some third-party repo is down, etc).
Yes, please, I don't want to be forced to work around automated
downloaders. e.g. Like OpenWrt's build system that wants to download
huge amounts of code if you don't watch it instead of just failing so
you can tell it to look *over there* where I've already downloaded 90%
of it! Of course, after it happens the first time you learn to be
more careful, but I would prefer to be told what the dependencies are
so that I can get them myself, or to be asked whether to download them
than just automatically downloading them.
> Regarding documentation, I remember throwing around ideas in irc some
> months ago about how to fold documentation from gen-class'ed libs into
> a library's broader javadoc. That would be a huge boon to those using
> clojure to build libraries that would be transparently usable by Java
> developers.
About documentation: I believe this has been mentioned before, but I
haven't been able to find the thread. Some functions are documented
like this:
"assoc[iate]. When applied to a map[...]"
This makes it difficult if you're looking for some function and don't
know the exact name.
e.g.:
user=> (find-doc "quotient")
nil
user=> (find-doc "quot\\[ient")
-------------------------
clojure.core/quot
([num div])
quot[ient] of dividing numerator by denominator.
nil
Also, while looking for the thread mentioning the above, I found
another unresolved documentation-related thread:
This is about the "count" function being difficult to find if you're
trying to find the "length" or "size" of something.
--
Michael Wood <esio...@gmail.com>
Michael Wood
Python did very well without a CPAN-alike.
Of course it had a pretty good standard library.
--
Michael Wood <esio...@gmail.com>
chris
Instead of stating the problem as a problem of arrogance, it would be
better to state it as without X, you can't get Y.
Specifically, without better documentation there exists a class of
users that will not use clojure and there exists a class of problems
that will take a lot longer to solve than they would otherwise take
with better documentation.
Without more testing it will be impossible to say that any given
change in subversion won't break a program. Really, this is an
impossible statement anyway although I realize that tests mitigate the
problem somewhat. Thus we can't use x.y.z. Every change would be
just x (somewhat absurd but at least correct).
Your point release theory sounds good if the use cases of your library
are very will defined and tested. A programming language doesn't fit
the testability coverage scenario very well as it is, well, a turing
complete language and thus it would be difficult at best to prove it
was working as it was before after *any* non-trivial change (difficult
meaning it is unlikely anyone here is a good enough mathematician to
do it in the average case).
I agree that more tests would be a good thing; I personally am not
going to touch clojure source without more tests that show a little
more of the intent of what the code is doing. But clients of clojure
*should* have sufficient tests to ensure that upgrading clojure will
not present a massive problem; it is impossible for Rich or anyone
else to provide this guarantee.
So the question is, what level of documentation and what level of test
coverage is important for a 1.0 release? What would you like to see
documented and tested?
I would like to see the datastructures' memory and performance bounds
tested, for instance.
Chris
On Apr 16, 2:58 pm, Howard Lewis Ship <hls...@gmail.com> wrote:
Meikel Brandmeyer
Am 16.04.2009 um 23:21 schrieb Michael Wood:
> Yes, please, I don't want to be forced to work around automated
> downloaders. e.g. Like OpenWrt's build system that wants to download
> huge amounts of code if you don't watch it instead of just failing so
> you can tell it to look *over there* where I've already downloaded 90%
> of it! Of course, after it happens the first time you learn to be
> more careful, but I would prefer to be told what the dependencies are
> so that I can get them myself, or to be asked whether to download them
> than just automatically downloading them.
To start collecting some Pros/Cons for the different
possibilities at there:
From my experiments with Ivy: You can just remove any
public repository from the search paths. So any download
will fail, telling you which dependencies could not be met.
In fact I run such a setup at work, where all external
dependencies are mirrored locally. So there is no network
access required.
Finally, Ivy makes it easy to setup such a mirror by
virtue of the ivy:install task.
Sincerely
Meikel
Howard Lewis Ship
>
> That is putting it quite strongly, Howard.
>
> Instead of stating the problem as a problem of arrogance, it would be
> better to state it as without X, you can't get Y.
>
> Specifically, without better documentation there exists a class of
> users that will not use clojure and there exists a class of problems
> that will take a lot longer to solve than they would otherwise take
> with better documentation.
>
> Without more testing it will be impossible to say that any given
> change in subversion won't break a program. Really, this is an
> impossible statement anyway although I realize that tests mitigate the
> problem somewhat. Thus we can't use x.y.z. Every change would be
> just x (somewhat absurd but at least correct).
>
> Your point release theory sounds good if the use cases of your library
> are very will defined and tested. A programming language doesn't fit
> the testability coverage scenario very well as it is, well, a turing
> complete language and thus it would be difficult at best to prove it
> was working as it was before after *any* non-trivial change (difficult
> meaning it is unlikely anyone here is a good enough mathematician to
> do it in the average case).
the standard library, which can
be unit tested. Testability is one of the foundations of functional
programming, so its
painful to see no actual tests.
>
> I agree that more tests would be a good thing; I personally am not
> going to touch clojure source without more tests that show a little
> more of the intent of what the code is doing. But clients of clojure
> *should* have sufficient tests to ensure that upgrading clojure will
> not present a massive problem; it is impossible for Rich or anyone
> else to provide this guarantee.
inspire confidence.
Konrad Hinsen
> What does 1.0 mean to you? Are we there yet? Any recommendations for
> the organization of the release branches, patch policy etc?
What I tacitly expect from a 1.0 release (or any official, numbered
release) is
- bug fixes without imposed changes in functionality for at least a year
- the promise not to introduce breaking changes in future releases
unless there is a very good reason to do so
- a clear indication of potentially breaking changes by a change in
version number
- an outline of how future changes will be handled so that I can
prepare for them in my own code management
For a 1.0 release in particular, I expect sufficient stability and
completeness for use in real-life projects.
From my own experience with today's Clojure, I'd say the stability
is there. I am less convinced about completeness, but that's mainly
because there are many things I haven't yet tried to do. Overall, the
discussions on the group don't leave the impression that there are
glaring holes anywhere. However, it is possible that many users are
relying on clojure-contrib for completeness, and if that is the case,
the status of clojure-contrib needs to be considered as well before a
1.0 release.
What I miss most for a 1.0 release is some idea of how future changes
will be handled, and what Clojure users can safely count on. For
example, every new function added to clojure.core will break code
that has chosen to use the same name for something else. While such
incompatibilities are easy to fix (with an exclusion in refer-
clojure), they are still a pain if they happen frequently. Another
point is multimethod dispatch. Various ideas have been discussed
here, and most of them, if adopted, are likely to break a lot of code
relying on the current approach.
As for bug fixes for a stable release, you pointed out that someone
would have to take care of them (mostly by backporting fixes in trunk
I guess). I don't think it will be hard to find a team of volunteers,
but it would be nice to arrange this before an official release. The
same team could also maintain a stable subset of clojure-contrib as a
kind of standard library.
Konrad.
jwhitlark
easy to compile, merge with java code, (or jython, or jruby, etc), and
a repl that came closer to something like IPython. A prototype lint
would be nice too, assuming it's possible for a lisp. And of course,
easier install.
The library stuff sounds good too.
Just off the top of my head.
MikeM
>
> What does 1.0 mean to you? Are we there yet? Any recommendations for
> the organization of the release branches, patch policy etc?
>
between breaking changes. It seems we are there, based on your
comments on API stability. HLShip's recommended x.y.z release
numbering policy would be fine, but from my perspective any release/
patch policy you adopt will be fine as long as it's clearly documented
what changes will be breaking vs new api's and bug fixes. At this time
I don't think there is much value in a system to manage patches to old
releases. Bugs could be reported and the latest version patched, and
then users could make the decision of whether to backport the patch
themselves or upgrade to the latest rev. If a significant user base of
an older release develops, this could be revisited (ie cross that
bridge when you come to it).
Paul Drummond
> 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.
Rich Hickey
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
e
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.
Ozzi Lee
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.
Luc Prefontaine
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
|
Luc Préfontaine Armageddon was yesterday, today we have a real problem... |
Paul Stadig
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
Stuart Halloway
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.
>
> the organization of the release branches, patch policy etc?
>
>
> Rich
>
> >
Matt Revelle
*snip*
> 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.
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
John Newman
Daniel Jomphe
> 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.
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.
Luke VanderHart
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
revoltingdevelopment
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
mikel
> 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.
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.
Cosmin Stejerean
- 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.
--
Cosmin Stejerean
http://offbytwo.com
mifrai
support."
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
Laurent PETIT
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 ....)
Mark Engelberg
> 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.
Tom Faulhaber
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
Paul Drummond
> 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.
Paul Drummond
> 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:
Paul.
Luke VanderHart
All of them work. Some are easier to use than others. There are
successful projects that use just about all of them. It's personal
preference. Rich is going to be doing most the contributing, let him
choose the VCS.
Period.
On Apr 17, 4:29 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> I guess there's really no perfect solution here :-(
>
> The question is :
>
> do you prefer to have some clojure users united against subversion, or
> divided by Rich not having chosen their preferred DVCS (Mercurial users vs
> Git users, not sure whether clojure needs those kinds of nonsense internal
> wars in the community ....)
>
Dan
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 ....)
In the meantime, I'm using svn-git to track clojure's official repo. The whole history of clojure is a mere 2 megabytes.
RZez...@gmail.com
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
Antony Blakey
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
mikel
On Apr 17, 8:31 pm, Antony Blakey <antony.bla...@gmail.com> 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.
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.
Laurent PETIT
We seem to be unanimous in preferring git.On Fri, Apr 17, 2009 at 4:29 PM, Laurent PETIT <lauren...@gmail.com> wrote:
I guess there's really no perfect solution here :-(
The question is :
do you prefer to have some clojure users united against subversion, or divided by Rich not having chosen their preferred DVCS (Mercurial users vs Git users, not sure whether clojure needs those kinds of nonsense internal wars in the community ....)
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
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 ;-)
Laurent PETIT
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
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
Stuart Sierra
> 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.
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
Paul Drummond
> [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.
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
Mark Reid
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
Konrad Hinsen
> 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.
John Newman
I do not agree with John Newman that the Java standard library
should be the Clojure standard library.
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.
John
Konrad Hinsen
> 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.
Timothy Pratley
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.
John Newman
John
Isak Hansen
>
> Feedback welcome,
>
1. I'd like to see a road map of sorts; plans for where Clojure will
be going with the next couple of releases.
2. Clojure-contrib -cleanup
- Move the clojure test suite to clojure itself
- Move 'worthy' libraries from contrib to the standard library?
- Make ClojureCLR and clojurescipt separate projects with their own
branches and so on.
3. I'd like to see the clojure source hooked up to some CI system,
along the lines of <http://ci.rubyonrails.org/>.
I know it's not a vote, but I use git as well.
> Rich
>
> >
>
Antony Blakey
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".
Tom Faulhaber
On Apr 18, 3:15 am, John Newman <john...@gmail.com> wrote:
> > I do not agree with John Newman that the Java standard library
> > should be the Clojure standard library.
>
> I'm not saying that. I'm saying that:
>
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.
Jeff Heon
<christopher.jay.jo...@gmail.com> wrote:
> Aside from that, I think you are right about the psychology of
> language adoption and book-buying. Declaring 1.0 to coincide with the
> content and publication date of Stuart's book is just an excellent
> idea, regardless of all the other issues raised so far.
I would second that and add that having a fixed version (be it .99, or
1.0 or 1.1 or whatever) is not useful only for the book, but also for
tooling.
It'd be nice to have IDE plugins versions, or Waterfront versions,
that depend on a fixed stable version instead of the latest snapshot
which my break or change stuff from one release to the next.
Of course, once there is that first stable version with which the tool
works, there's no harm in having alpha or beta release of the tool
version using the latest Clojure snapshot.
Plus it's always nice to be able to develop a library or whatever and
assigning a language version to it, like we do with Java or .Net.
Vincent Foley
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
Rich Hickey
On Apr 17, 5:21 pm, Tom Faulhaber <tomfaulha...@gmail.com> 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 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
Phil Hagelberg
> 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
Stuart Sierra
> I imagine a (clojure-version) function returning:
>
> {:major 1 :minor 0 :release 0}
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
Phil Hagelberg
> On Apr 20, 1:48 pm, Rich Hickey <richhic...@gmail.com> wrote:
>> I imagine a (clojure-version) function returning:
>>
>> {:major 1 :minor 0 :release 0}
>
> I'd suggest calling :release something else, like :revision
> or :patch. "release" sounds like a bigger number than major/minor.
> Other than that, makes sense to me.
The term I've often seen is :bugfix for the least-significant version segment.
-Phil
Laurent PETIT
>
> On Apr 20, 1:48 pm, Rich Hickey <richhic...@gmail.com> wrote:
> > I imagine a (clojure-version) function returning:
> >
> > {:major 1 :minor 0 :release 0}
>
> I'd suggest calling :release something else, like :revision
> or :patch. "release" sounds like a bigger number than major/minor.
> Other than that, makes sense to me.
I like the term "service" used in Eclipse terminology:
"the service segment indicates bug fixes"
(The numbering scheme for Eclipse uses major, minor, service and
qualifier : "the qualifier segment indicates a particular build").
(http://wiki.eclipse.org/Version_Numbering#Guidelines_on_versioning_plug-ins)
--
Laurent Petit
Laurent PETIT
> 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
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)
Daniel Jomphe
> > I'd suggest calling :release something else, like :revision
> > or :patch.
> "the service segment indicates bug fixes"
>
> (The numbering scheme for Eclipse uses major, minor, service and
> qualifier : "the qualifier segment indicates a particular build").
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
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
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
<groupId>:<artifactId>:<packaging>:<version> to identify a particular
artifact e.g. library. GroupId + Artifact Id is a qualified name -
think java package name. Packaging specifies how the artifact is
packaged e.g. jar or war, but it doesn't contribute the id of the
project. Version numbers are as you expect, but can be suffixed with '-
SNAPSHOT', which effectively creates a distinct subspace of versions
ordered by creation date. By depending on a 'a.b.c-SNAPSHOT' version,
you get the latest (by date) artifact marked with 'a.b.c-SNAPSHOT'.
When you release the artifact you remove the '-SNAPSHOT'. In effect
the suffix creates two different versioning spaces, one of which is
strictly determined by the hierarchic numeric ordering, and another
that allows duplicates ordered by date within a specific
hierarchically ordered version. AFAIK, an 'a.b.c-SNAPSHOT' version
will not satisfy a request for 'a.b.c' e.g. -SNAPSHOT is not a further
qualifier.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The project was so plagued by politics and ego that when the engineers
requested technical oversight, our manager hired a psychologist instead.
-- Ron Avitzur
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
> <groupId>:<artifactId>:<packaging>:<version> to identify a
> particular artifact e.g. library. GroupId + Artifact Id is a
> qualified name - think java package name. Packaging specifies how
> the artifact is packaged e.g. jar or war, but it doesn't contribute
> the id of the project. Version numbers are as you expect, but can be
> suffixed with '-SNAPSHOT', which effectively creates a distinct
> subspace of versions ordered by creation date. By depending on a
> 'a.b.c-SNAPSHOT' version, you get the latest (by date) artifact
> marked with 'a.b.c-SNAPSHOT'. When you release the artifact you
> remove the '-SNAPSHOT'. In effect the suffix creates two different
> versioning spaces, one of which is strictly determined by the
> hierarchic numeric ordering, and another that allows duplicates
> ordered by date within a specific hierarchically ordered version.
> AFAIK, an 'a.b.c-SNAPSHOT' version will not satisfy a request for
> 'a.b.c' e.g. -SNAPSHOT is not a further qualifier.
This BTW presumes a fairly simplistic dependency selection mechanism.
In a previous life I did a lot of work with dependency algebras, and a
far more powerful solution for managing configuration is to allow
artifacts to be annotated with multidimensional versioning attributes
organized by feature, using an ordered unification based configuration
resolution mechanism. Somewhat like versioned requires/provides but
with richer semantics.
My experience was such systems are too complicated for mass
deployment, and their use needs to be motivated by a significant
configuration management requirement, which is why I suggest sticking
to the far simpler maven/ivy POM model.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
All that is required for evil to triumph is that good men do nothing.
Daniel Jomphe
> I'm unfamiliar with the POM version coordinate system - any hints?
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.
Mark Derricutt
somehow, at both the gen-class and method level at least.
Mark
Laurent PETIT
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 <daniel...@gmail.com>:
AndrewC.
>
> I'm unfamiliar with the POM version coordinate system - any hints?
>
> Rich
http://www.sonatype.com/books/maven-book/reference/simple-project-sect-maven-coordinates.html
Laurent PETIT
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
>
>
> >
>
Daniel Jomphe
> I have not followed maven2 concerning this "qualifier" thing.
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)
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
same POM but differ in their content."
clojure data structures as code, I believe it makes sense to introduce
a new conventional classifier which is alien to purely java-based
projects but makes sense to clojure projects.
Following this, a conventional maven packaging of clojure would yield
the following:
clojure-1.0.0-<snapshot>.jar
clojure-1.0.0-<snapshot>-slim.jar
clojure-1.0.0-<snapshot>-javadoc.jar
clojure-1.0.0-<snapshot>-sources.jar
Now, let's suppose we really don't care about the javadoc-only
packaging. Upon official release:
clojure-1.0.0.jar
clojure-1.0.0-slim.jar
clojure-1.0.0-sources.jar
clojure-1.0.1-<snapshot>.jar
clojure-1.0.1-<snapshot>-slim.jar
clojure-1.0.1-<snapshot>-sources.jar
clojure-1.1.0-<snapshot>.jar
clojure-1.1.0-<snapshot>-slim.jar
clojure-1.1.0-<snapshot>-sources.jar
Howard has already done this for the snapshot of 1.0.0, but he
versioned it 1.0:
http://tapestry.formos.com/maven-snapshot-repository/org/clojure/clojure-lang/1.0-SNAPSHOT/
Paul Stadig
On Apr 20, 2009, at 7:02 PM, Antony Blakey wrote:
> On 21/04/2009, at 5:12 AM, Laurent PETIT wrote:
>
>> { :major 1 :minor 0 :release 0 :status :SNAPSHOT }
>> then
>> { :major 1 :minor 0 :release 0 :status :RC1 } (release candidate 1)
>> then
>> { :major 1 :minor 0 :release 0 :status :RC2 } (release candidate 2)
>> etc.
>> and finally
>> { :major 1 :minor 0 :release 0 :status :GA1 } (Global Availibility 1)
I'm unfamiliar with the POM version coordinate system - any hints?
Rich
Others have commented on the whole groupId, artifactId, etc., etc. But in terms of the parts of the version number, they are named <major>.<minor>.<incremental>-<qualifier> as documented here:
http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html
Paul
Howard Lewis Ship
>
> On Thu, Apr 16, 2009 at 6:53 PM, Rich Hickey <richh...@gmail.com> wrote:
>>
>> Feedback welcome,
>>
>
> 1. I'd like to see a road map of sorts; plans for where Clojure will
> be going with the next couple of releases.
>
> 2. Clojure-contrib -cleanup
> - Move the clojure test suite to clojure itself
> - Move 'worthy' libraries from contrib to the standard library?
> - Make ClojureCLR and clojurescipt separate projects with their own
> branches and so on.
>
> 3. I'd like to see the clojure source hooked up to some CI system,
> along the lines of <http://ci.rubyonrails.org/>.
>
>
> I know it's not a vote, but I use git as well.
>
>
>> Rich
>>
>> >
>>
>
> >
>
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
Daniel Jomphe
> Others have commented on the whole groupId, artifactId, etc., etc. But in
> terms of the parts of the version number, they are named
> <major>.<minor>.<incremental>-<qualifier> as documented here:
>
Thanks for the info.
So I was wrong in two ways:
1. There's in fact a convention for version strings: M.m.i-qualifier
2. The string "SNAPSHOT" may appear anywhere inside the version
string.
Keeping SNAPSHOT at the end and adding a "rc1" qualifier, to
illustrate:
version: 1.0.0-rc1-SNAPSHOT
yields: clojure-1.0.0-rc1-<snapshot>.jar
(and ...-slim.jar, ...-sources.jar)
Laurent PETIT
2009/4/21 Daniel Jomphe <daniel...@gmail.com>:
>
> version: 1.0.0-rc1-SNAPSHOT
> yields: clojure-1.0.0-rc1-<snapshot>.jar
> (and ...-slim.jar, ...-sources.jar)
There it is. But why having "<snapshot>" in the name of the jar,
shouldn't it just be "SNAPSHOT" (as far as I remember) ?
That is:
{ :major 1 :minor 0 :incremental "0-rc1-SNAPSHOT" }
gives version: 1.0.0-rc1-SNAPSHOT
yields: clojure-1.0.0-rc1-SNAPSHOT.jar
(and ...-slim.jar, ...-sources.jar)
--
Laurent
Daniel Jomphe
> > version: 1.0.0-rc1-SNAPSHOT
> > yields: clojure-1.0.0-rc1-<snapshot>.jar
> > (and ...-slim.jar, ...-sources.jar)
>
> There it is. But why having "<snapshot>" in the name of the jar,
> shouldn't it just be "SNAPSHOT" (as far as I remember) ?
>
> That is:
>
> { :major 1 :minor 0 :incremental "0-rc1-SNAPSHOT" }
> gives version: 1.0.0-rc1-SNAPSHOT
> yields: clojure-1.0.0-rc1-SNAPSHOT.jar
> (and ...-slim.jar, ...-sources.jar)
"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/
Laurent PETIT
Rich Hickey
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
Laurent PETIT
2009/4/22 Rich Hickey <richh...@gmail.com>:
> [...]
> {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
> [...]
> Possible
> values of :qualifier include :rc, :beta etc,
> and :interim will be true for non-release builds.
I don't think :qualifier is used correctly here (at least if you want
to give it the same meaning as what was suggested previously in the
thread).
The qualifier is there to be able to produce several different outputs
(e.g. jars in our case) from the same version number.
A version is fully qualified with :major + :minor + :incremental + :interim
An output made from the version is fully qualified with :major +
:minor + :incremental + :interim + :qualifier.
If we look at what are the different outputs currently are for
clojure, :qualifier can have 3 values:
"" (empty string) : for producing clojure-M.m.i.jar
"slim" : for producting clojure-M.m.i-slim.jar
"sources" : for producing clojure-M.m.i-sources.jar
:qualifier will be needed in projects which depend upon clojure, to
fully qualify which jar among the 3 possibilities one want to depend
upon.
Regards,
--
Laurent
Laurent PETIT
:qualifier seems totally appropriate here, sorry for the noise,
--
Laurent
2009/4/22 Laurent PETIT <lauren...@gmail.com>:
Daniel Jomphe
> 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?
"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.
Daniel Jomphe
"capitulate; let's just manually hard-code the version in the three
places; anyways, we won't have to change it often".
Laurent PETIT
>
> 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
Howard Lewis Ship
<version> 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.
Rich Hickey
On Apr 22, 12:41 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> 2009/4/22 Rich Hickey <richhic...@gmail.com>:
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
Laurent PETIT
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
Rich Hickey
On Apr 23, 11:24 am, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> 2009/4/23 Rich Hickey <richhic...@gmail.com>:
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
Christophe Grand
> 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)