On May 2, 1:02 am, Laurent PETIT laurent.pe...@gmail.com wrote:
Note: I strongly suggest that the clojure.version.interim property
remains true in svn, so that it's not possible to inadvertently
release a version too early.
Just to clarify - are you suggesting I should just change
2009/5/4 Phil Hagelberg technoma...@gmail.com:
On May 2, 1:02 am, Laurent PETIT laurent.pe...@gmail.com wrote:
Note: I strongly suggest that the clojure.version.interim property
remains true in svn, so that it's not possible to inadvertently
release a version too early.
Just to
2009/5/1 Rich Hickey richhic...@gmail.com
On Apr 26, 6:54 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
I've created issue 110 with the patch attached in clojure's google code
project.
Note: I strongly suggest that the clojure.version.interim property
remains true in svn, so
On Apr 26, 6:54 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
I've created issue 110 with the patch attached in clojure's google code
project.
Note: I strongly suggest that the clojure.version.interim property
remains true in svn, so that it's not possible to inadvertently
release a
On Apr 27, 5:01 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
New patch with corrections posted to google code,
That patch has been applied. I recommend everyone who is able to
please try out the latest version from SVN - this will become a
release candidate. The patch generates jar files
Hi,
2009/4/28 Rich Hickey richhic...@gmail.com:
On Apr 27, 5:01 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
New patch with corrections posted to google code,
That patch has been applied. I recommend everyone who is able to
please try out the latest version from SVN - this will
On Apr 28, 2009, at 15:26, Rich Hickey wrote:
That patch has been applied. I recommend everyone who is able to
please try out the latest version from SVN - this will become a
release candidate.
After modifying my build scripts to take into account the new name of
the jar file, all the
Shouldn't ant clean remove all generated files, including jars from
the source tree?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To
2009/4/28 Marko Kocić marko.ko...@gmail.com:
Shouldn't ant clean remove all generated files, including jars from
the source tree?
I also asked this to myself, but it was the previous behaviour and I
didn't want to do more than one thing in the patch.
2009/4/28 Laurent PETIT laurent.pe...@gmail.com:
2009/4/28 Marko Kocić marko.ko...@gmail.com:
Shouldn't ant clean remove all generated files, including jars from
the source tree?
I also asked this to myself, but it was the previous behaviour and I
didn't want to do more than one thing in
Now that the files are versioned, should ant clean do
* 1. a brute force equivalent of rm clojure*.jar in %CLOJURE_INSTALL%
* 2. or just try to delete clojure jars with names equal to the
current values in version.properties
I prefer 1., since with 2. if version numbers have changed in
Dear Clojurians,
Am 28.04.2009 um 15:26 schrieb Rich Hickey:
Feedback welcome,
I updated my Clojure+Ivy patch to use the new
version information. Using the publish target is
only possible on none-interim releases and
publishes the given version.
publish-local will use SVNAnt to extract the
Rich, refer to the patch described by Stephen Gilardi at
http://groups.google.com/group/clojure/msg/2b7dd55d9f766125 (which
makes it possible to run Clojure under z/OS).
Based on Steve and Laurent PETIT's comments in that thread, I gather
that the UTF-8 vs platform-default issue has been around
New patch with corrections posted to google code,
regards,
--
laurent
2009/4/27 Laurent PETIT laurent.pe...@gmail.com:
I've created issue 110 with the patch attached in clojure's google code
project.
Hi Rich, Howard,
I'll answer to both at the same time, trying to reconcile things a
On 26 avr, 15:04, Rich Hickey richhic...@gmail.com wrote:
On Apr 24, 1:57 pm, Howard Lewis Ship hls...@gmail.com wrote:
Another option is for the version number to be in build.xml, and for
it to generate a runtime file (so that Clojure can know its own
version number) and set the
On Apr 26, 9:18 am, lpetit laurent.pe...@gmail.com wrote:
On 26 avr, 15:04, Rich Hickey richhic...@gmail.com wrote:
On Apr 24, 1:57 pm, Howard Lewis Ship hls...@gmail.com wrote:
Another option is for the version number to be in build.xml, and for
it to generate a runtime file (so
I've created issue 110 with the patch attached in clojure's google code project.
Hi Rich, Howard,
I'll answer to both at the same time, trying to reconcile things a bit.
Howard, my first patch was already along the lines of what you
described below, I think (concerning the fact to use ant to
Konrad Hinsen a écrit :
What I miss most for a 1.0 release is some idea of how future changes
will be handled, and what Clojure users can safely count on. For
example, every new function added to clojure.core will break code
that has chosen to use the same name for something else. While
Laurent PETIT a écrit :
2009/4/24 Christophe Grand christo...@cgrand.net:
Konrad Hinsen a écrit :
What I miss most for a 1.0 release is some idea of how future changes
will be handled, and what Clojure users can safely count on. For
example, every new function added to clojure.core
2009/4/24 Christophe Grand christo...@cgrand.net:
Konrad Hinsen a écrit :
What I miss most for a 1.0 release is some idea of how future changes
will be handled, and what Clojure users can safely count on. For
example, every new function added to clojure.core will break code
that has chosen
Another option is for the version number to be in build.xml, and for
it to generate a runtime file (so that Clojure can know its own
version number) and set the version number inside a generated pom.xml.
You can use Ant resource copying with filters to accomplish both
these goals.
On Thu, Apr
2009/4/23 Rich Hickey richhic...@gmail.com:
On Apr 22, 12:41 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
for interim versions and
{:major 1, :minor 0,
On Apr 21, 12:18 pm, Daniel Jomphe danieljom...@gmail.com wrote:
Paul Stadig wrote:
Others have commented on the whole groupId, artifactId, etc., etc. But in
terms of the parts of the version number, they are named
major.minor.incremental-qualifier as documented here:
Hi,
2009/4/22 Rich Hickey richhic...@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
OOooops sorry, I mistook qualifier for classifier,
:qualifier seems totally appropriate here, sorry for the noise,
--
Laurent
2009/4/22 Laurent PETIT laurent.pe...@gmail.com:
Hi,
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{:major 1, :minor 0, :incremental 0, :qualifier :rc1
Daniel Jomphe wrote:
Rich Hickey wrote:
I don't mind the build producing clojure-1.0.0.jar etc, but it doesn't
now. The master build is Ant. Where is the best place to put the
version info so it can be leveraged by Ant, Maven and the clojure core
runtime in order to produce
2009/4/22 Rich Hickey richhic...@gmail.com:
[...]
{:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true}
for interim versions and
{:major 1, :minor 0, :incremental 0}
for releases. :interim tracks the SNAPSHOT segment of the version
string.
[...]
I don't mind the build
On Apr 21, 1:52 am, Rich Hickey richhic...@gmail.com wrote:
I'm unfamiliar with the POM version coordinate system - any hints?
Rich
1 Pager on coordinates from the 'definitive guide'
http://www.sonatype.com/books/maven-book/reference/simple-project-sect-maven-coordinates.html
2009/4/21 AndrewC. mr.bl...@gmail.com:
On Apr 21, 1:52 am, Rich Hickey richhic...@gmail.com wrote:
I'm unfamiliar with the POM version coordinate system - any hints?
Rich
1 Pager on coordinates from the 'definitive guide'
Laurent PETIT wrote:
I have not followed maven2 concerning this qualifier thing.
Right. The first (small) part of my post, which referred to yours, was
strictly about versioning, and specifically about the end of the
version string, related to snapshots.
Then I addressed the classifier as
On Mon, Apr 20, 2009 at 8:52 PM, Rich Hickey richhic...@gmail.com wrote:
On Apr 20, 2009, at 7:02 PM, Antony Blakey wrote:
On 21/04/2009, at 5:12 AM, Laurent PETIT wrote:
{ :major 1 :minor 0 :release 0 :status :SNAPSHOT }
then
{ :major 1 :minor 0 :release 0 :status :RC1 } (release
On Sat, Apr 18, 2009 at 5:34 AM, Isak Hansen isak.han...@gmail.com wrote:
On Thu, Apr 16, 2009 at 6:53 PM, Rich Hickey richhic...@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.
Paul Stadig wrote:
Others have commented on the whole groupId, artifactId, etc., etc. But in
terms of the parts of the version number, they are named
major.minor.incremental-qualifier as documented here:
http://www.sonatype.com/books/maven-book/reference/pom-relationships-...
Thanks for the
Laurent PETIT wrote:
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
2009/4/21 Daniel Jomphe danieljom...@gmail.com:
Laurent PETIT wrote:
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
Stuart Sierra the.stuart.sie...@gmail.com writes:
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
2009/4/20 Stuart Sierra the.stuart.sie...@gmail.com
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
2009/4/20 Rich Hickey richhic...@gmail.com:
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
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
Laurent PETIT wrote:
I'd suggest calling :release something else, like :revision
or :patch.
I like the term service used in Eclipse terminology:
the service segment indicates bug fixes
(The numbering scheme for Eclipse uses major, minor, service and
qualifier : the qualifier segment
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
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
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
Rich Hickey wrote:
I'm unfamiliar with the POM version coordinate system - any hints?
Maven takes the version as whatever-formatted string, but recognizes a
conventional (.endsWith 1.0.0-SNAPSHOT -SNAPSHOT), like described
by Laurent PETIT. So whatever-SNAPSHOT means we're going someday to
For a 1.0 release I'd love to see some support for JDK annotations
somehow, at both the gen-class and method level at least.
Mark
On Fri, Apr 17, 2009 at 4:53 AM, Rich Hickey richhic...@gmail.com wrote:
This is mostly about - does it work? Is it relatively free of bugs? Is
it free of gaping
Daniel,
I have not followed maven2 concerning this qualifier thing.
Would it be corrrect to say that, to further extend you examples, one
the qualifiers could be slim, since clojure ant already has such a
target.
Or would a slim jar of clojure have to had another artifactId ? (I
don't think
On Apr 17, 2:47 pm, revoltingdevelopment
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,
On Apr 17, 2:47 pm, revoltingdevelopment
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,
For a 1.0 release, I think that having a number that we can point at
and say this software will work with that version of the language is
important. I think a little bit of polish wouldn't be bad either: I
saw that Scala ships with bash and batch scripts to launch scala and
scalac. I think
I'm eager to see Clojure turn 1.0 because it is a fantastic language
that deserves to be even more popular than it already is. I believe it
is time to put the message out there that clj has made the journey
from something to toy with to a serious language or even the next
big thing. Clojure has
Well, perhaps if str-utils becomes the universal standard for string
operations, it would be rolled into Clojure come 2.0?
On Sat, Apr 18, 2009 at 2:58 PM, Konrad Hinsen konrad.hin...@laposte.netwrote:
On 18.04.2009, at 12:15, John Newman wrote:
2) One way to maintain Clojure's flexibility
I do not agree with John Newman that the Java standard library
should be the Clojure standard library.
I'm not saying that. I'm saying that:
1) Requiring Java's standard library on every system is unfortunate enough
-- it's too big for some of the smaller devices coming out now. And,
2) One
On Thu, Apr 16, 2009 at 6:53 PM, Rich Hickey richhic...@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
On 18/04/2009, at 5:38 PM, Konrad Hinsen wrote:
On 18.04.2009, at 01:13, Dan wrote:
do you prefer to have some clojure users united against subversion,
or divided by Rich not having chosen their preferred DVCS
(Mercurial users vs Git users, not sure whether clojure needs those
kinds of
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:
John, I misunderstood what you were trying to say. My apologies!
There seems to be some
On 16.04.2009, at 18:53, Rich Hickey wrote:
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
What I'd really like to see are better command line tools. Make it
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.
2009/4/16 Rich Hickey richhic...@gmail.com:
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
Thanks all for the feedback. One impression I get is that it seems the
existing community is getting along ok on trunk, so perhaps we also
need to consider those not yet using Clojure, possibly even because of
a lack of 1.0.
I joked about book authors, but I'd like to make it clear that I think
One possible approach that just occurred to me waking up this morning is to
just do it. The very idea that now is a good time to ask the question is a
milestone. 1.0 marks the time that the question was asked as to what it
would take for there to be a 1l0! That was a typo, I meant 1.0, but why
I feel the urge to drop a couple more pennies into this thread.
Trunk should NOT be used for day-to-day development and
experimentation. There should be a branch for that.
Trunk should NEVER be broken. Comprehensive tests need to run and pass
on the development branch before those changes are
a) Stability ? Looks pretty fine to me up to now...
b) Getting 1.0 out ? Absolutely needed to increase the level of
acceptance of Clojure. Future releases will have to clearly documented
as to what they fix,
what changes have been done to the language itself and what it may
break in user
Strangely enough, for me version 1.0 would mean the version of Clojure
described in the book Programming Clojure by Stuart Halloway.
It would be a version that I could download directly even though newer
versions would appear afterward so the book and the Clojure version
are consistent with one
On Fri, Apr 17, 2009 at 9:21 AM, Rich Hickey richhic...@gmail.com wrote:
snip
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
I would love to see 1.0, and the sooner the better. At Relevance we
are doing real work in Clojure today.
As for wish list I would love to see improvements to the development
process:
* move from svn to git
* move regression tests from contrib into clojure itself
But neither of these need
On Apr 17, 9:21 am, Rich Hickey richhic...@gmail.com wrote:
*snip*
Git is not going to happen any time soon, great as it may
be, given the current lack of infrastructure (google code) and tools
support. Is there some respect in which this impacts the core? It
would seem dangerous to marry any
I vote for 1.0 as soon as possible. Seems stable to me. I'm working on a
chat application and when we moved to fully lazy sequences, still none of my
code broke.
I vote no on making contrib the Standard Library. The Java Standard
Library is large enough. I would like contrib to be easier to
Overall, I'm getting feature requests (more change!) and not a strong
drive for 1.0 stability. If you feel otherwise, please speak up.
Otherwise, my conclusion is that 1.0 may be more important for not-yet-
users wary of working from source.
My thought was that I very much like that you
To me, major version numbers means no more nor less than a marker
pointing to a stable, consistent release that can be easily referred
to consistently by everyone. It doesn't mean that there can't be
major, breaking changes for 2.0 (or even 1.5, whatever). I don't even
care what features are in
Rich,
A list of the things you know you want to add or change would be
useful to this discussion. For all we know, there could be a game-
changer on that list that would suggest holding off on 1.0.
Aside from that, I think you are right about the psychology of
language adoption and
On Apr 17, 8:21 am, Rich Hickey richhic...@gmail.com wrote:
Thanks all for the feedback. One impression I get is that it seems the
existing community is getting along ok on trunk, so perhaps we also
need to consider those not yet using Clojure, possibly even because of
a lack of 1.0.
I
On Thu, Apr 16, 2009 at 11:53 AM, Rich Hickey richhic...@gmail.com wrote:
[...]
- Development process stability
Currently all new work (fixes and enhancements) occurs in trunk.
There's no way to get fixes without also getting enhancements. I think
this is the major missing piece in
Rich says Git is not going to happen any time soon, great as it may
be, given the current lack of infrastructure (google code) and tools
support.
I'm curious as to why github isn't a viable alternative to google
code? Now that it has issue tracking, I don't see the advantages of
choosing
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
On Fri, Apr 17, 2009 at 6:21 AM, Rich Hickey richhic...@gmail.com wrote:
Overall, I'm getting feature requests (more change!) and not a strong
drive for 1.0 stability. If you feel otherwise, please speak up.
Otherwise, my conclusion is that 1.0 may be more important for not-yet-
users wary of
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
2009/4/17 Laurent PETIT laurent.pe...@gmail.com:
do you prefer to have some clojure users united against subversion, or
divided by Rich not having chosen their preferred DVCS (Mercurial users vs
Git users, not sure whether clojure needs those kinds of nonsense internal
wars in the community
2009/4/17 Tom Faulhaber tomfaulha...@gmail.com:
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
My .02 on the version control issue:
All of them work. Some are easier to use than others. There are
successful projects that use just about all of them. It's personal
preference. Rich is going to be doing most the contributing, let him
choose the VCS.
Period.
On Apr 17, 4:29 pm, Laurent
On Fri, Apr 17, 2009 at 4:29 PM, Laurent PETIT laurent.pe...@gmail.comwrote:
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
As with any decision, it will be impossible to please everyone. I
think the Git vs Subversion talk is way off topic at this point, but
to each his own.
Rich, I think it really depends on what *YOU* want Clojure to be. If
you want to take a Haskell like approach and avoid success at all
costs
Hi Rich,
Every decision is a balance and will have good and bad aspects, of course.
In the good aspects of releasing a 1.0 quickly, is the fact that (coupled
with Stu's book release) I can try to more succesfully promote clojure
internally in my company (Ah, these psychological issues ;-).
In
On Apr 17, 9:21 am, Rich Hickey richhic...@gmail.com wrote:
A library management system seems like a tall order for a language
1.0. It is certainly an interesting and useful pursuit, but given the
variety of approaches and opinions therein, it seems a bit out in
front of us.
Yes. I retract
2009/4/18 Laurent PETIT laurent.pe...@gmail.com:
[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
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
I'm a relatively new user of Clojure and thought I'd add my
perspective to the pile regarding what I would expect from a 1.0
release.
My biggest frustrations with Clojure as a newcomer were:
1. Setting it up so it was easy to use across projects
2. The API documentation
While the documentation
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
There's no way to get fixes without also getting enhancements
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
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
On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote:
What does 1.0 mean to you? Are we there yet? Any recommendations for
the organization of the release branches, patch policy etc?
I would like to see, concurrent with 1.0, some kind of library
management system. As noted before,
It sounds nice, but I experienced massive amounts of pain trying to get the
eclipse git plugin to work on mac ... eventually punted back to SVN. To me
version control should be well integrated with an editor ... bottom line ...
much more important than the given features of the version control
On Thu, Apr 16, 2009 at 10:39 AM, dysinger dysin...@gmail.com wrote:
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
What does 1.0 mean to you? Are we there yet? Any recommendations for
the organization of the release branches, patch policy etc?
To me, beside what was already said, it means a deprecation policy. I like
Python's. First release after deprecated changes are decided, code works as
is but
Ideally, since backward compatibility is a big selling point of Java.
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.
On Apr 16, 2009, at 1:56 PM, Stuart Sierra wrote:
On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote:
What does 1.0 mean to you? Are we there yet? Any recommendations for
the organization of the release branches, patch policy etc?
I would like to see, concurrent with 1.0, some
I am all for a standard packaging/build system but what ever it is it
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
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
And that requires shoe-horning new stuff in the old
OSGi is becoming the de facto standard for solving the runtime issues
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,
On Thu, Apr 16, 2009 at 9:53 AM, Rich Hickey richhic...@gmail.com wrote:
People (and not just book authors :) often ask - whither 1.0? [Ok,
maybe they don't use 'whither']. The fact remains, some people want a
1.0 designation, and I'm not unwilling, providing we as a community
can come to an
On Thu, Apr 16, 2009 at 9:10 PM, Chas Emerick cemer...@snowtide.com
[...]
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
1 - 100 of 104 matches
Mail list logo
