Clojure 1.2.1?

[Paul Stadig]

The idea of a 1.2.1 release has been mentioned before here on the list and in IRC. Rich has mentioned that we should have the discussion here. I submit the following for consideration:

1. 1.3/2.0 may or may not be completed soon. There are currently 21 open issues to be resolved.

2. Even if 1.3/2.0 is completed soon, it may still be desirable for people with existing code bases to get some bugfixes without having to update for 1.3/2.0 compatibility. I'm thinking of two issues in particular that would require code changes: the numerics changes (which will probably not impact very many people so it may be a non-issue), and the dynamic var changes (less clear to me what the impact of this will be). In regard to the dynamic var changes, it was my impression that the final 1.3/2.0 release will include automatically marking earmuffed vars as dynamic, but others I have talked to thought that would be removed from the final version. Are there any changes in 1.3/2.0 that would affect AOT compatibility? I'm not under the impression that I'm speaking as an expert on any of these issues, so correct me if I'm wrong.

Also consider, that it is not always up to you whether you can be 1.3/2.0 compatible if your dependencies are not.

3. Some of the bugs in 1.2 are things that are relatively simple fixes (and have already been fixed) but for which there is no workaround in user code. This is the particular class of issues I am thinking of for a 1.2.1 release. Two examples: the stack overflow error in Keyword.intern (which we have seen crop up several times in our hugely distributed Clojure app at Sonian, and its a bit of a drag), and the multimethod/restfn memory leak (which we have also seen at Sonian and required us to rewrite some of our code so as not to use multimethods *sad panda*).

There is a wiki page (http://dev.clojure.org/display/design/Release+1.2.1) with some possibilities for inclusion into 1.2.1. Are there other issues for which there is no workaround in user code? Is there enough of a warrant to cut a 1.2.1 release?


Paul

[Cosmin Stejerean]

If we have fixes that are ready and solve important issues in 1.2.0 without breaking backwards compatibility then I vote for cutting a 1.2.1 release. Any arguments against 1.2.1?

- Cosmin

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To post to this group, send email to cloju...@googlegroups.com.
To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.

--
Cosmin Stejerean
http://offbytwo.com

[Stuart Halloway]

We (Clojure/core) discuss this on Friday, so please get your suggestions registered by then.

People that are impacted by the 1.2 issues: is moving to 1.3 an option? What issues in 1.3 stand in your way? Do we need to label a release "beta" instead of "alpha"? Which tickets would be must-fix before beta?

Stu

[Chouser]

On Wed, Mar 9, 2011 at 1:11 PM, Stuart Halloway
<stuart....@gmail.com> wrote:
> We (Clojure/core) discuss this on Friday, so please get your suggestions
> registered by then.
> People that are impacted by the 1.2 issues: is moving to 1.3 an option? What
> issues in 1.3 stand in your way? Do we need to label a release "beta"
> instead of "alpha"? Which tickets would be must-fix before beta?

At work, the biggest drivers of the Clojure versions we use are the
libraries we need. This is somewhat painful because some (congomongo)
are incompatible with 1.3 while others (lazytest) depend on 1.3. So
we're deep into 1.3 now, and phasing out our dependence on libs that
are incompatible.

Thus, 1.2.1 isn't interesting to me, personally.

--Chouser

PS. Note how none of this has anything to do with language bugs or 2.0
vs. 1.3 naming. :-)

[Phil Hagelberg]

On Wed, Mar 9, 2011 at 10:11 AM, Stuart Halloway
<stuart....@gmail.com> wrote:
> We (Clojure/core) discuss this on Friday, so please get your suggestions
> registered by then.
> People that are impacted by the 1.2 issues: is moving to 1.3 an option? What
> issues in 1.3 stand in your way? Do we need to label a release "beta"
> instead of "alpha"? Which tickets would be must-fix before beta?

I think adapting to changes in contrib is going to be a bigger job for
some projects to make rather than the changes to Clojure itself. Also
while the dynamicity changes will not affect any of our production
code, there are many, many places in our test suite where binding is
used in a way that would not be kosher in "real life" and will break
in 1.3. Even if we have to spend our own manpower pushing 1.2.1
through it would be less work than upgrading right now.

Also some people are also going to be wary of upgrading to _any_
pre-release version, which in some contexts may be reasonable.

-Phil

[Stuart Halloway]

> Also
> while the dynamicity changes will not affect any of our production
> code, there are many, many places in our test suite where binding is
> used in a way that would not be kosher in "real life" and will break
> in 1.3.

Doesn't with-redefs solve this?

Stu

[Fogus]

> Doesn't with-redefs solve this?

Only if they don't care about thread-local bindings in their tests.

[Phil Hagelberg]

Hmmm... It probably would in most cases, but it also makes
parallelization of tests a trickier problem.

-Phil

[Stuart Sierra]

What are the breaking changes in clojure-contrib from 1.2 to 1.3, other than modularization?  We could re-release clojure-contrib 1.2 as a source-only JAR that would be compatible with Clojure.Next.  Or is modularization itself the issue?  Clojure-contrib 1.3 is already available as a single JAR.

Interface-wise, I'm aware of only one breaking change: c.c.logging/error changed argument order.

-S

[Phil Hagelberg]

We looked into upgrading a while ago and I recall having a number of
issues, but it looks like those have been resolved.

-Phil

[Rich Hickey]

I presume this still includes cases of wanting to change the meaning
of things for code other than your own?

If not, it begs the question of debug builds, where a debug build
would have relaxed rebinding semantics. Of course, if you wanted to
change the meaning of things for others, you'd need a debug build from
them as well.

Another idea I had recently was to tie this to a mechanism similar to
that used by Java's assert. Then you would have a runtime flag, which
would have to be set prior to code being loaded, that could set the
different var behavior, with no overhead when not used
(theoretically). This would not require different builds.

Rich

[Paul Stadig]

On Thu, Mar 10, 2011 at 9:01 AM, Rich Hickey <richh...@gmail.com> wrote:

I presume this still includes cases of wanting to change the meaning of things for code other than your own?

If not, it begs the question of debug builds, where a debug build would have relaxed rebinding semantics. Of course, if you wanted to change the meaning of things for others, you'd need a debug build from them as well.

Another idea I had recently was to tie this to a mechanism similar to that used by Java's assert. Then you would have a runtime flag, which would have to be set prior to code being loaded, that could set the different var behavior, with no overhead when not used (theoretically). This would not require different builds.

Rich

I guess we're kinda getting off the topic of a 1.2.1 release here, but for what it's worth, I'm not sure I'm in favor of a runtime flag that would change the behavior of var bindings, and potentially the behavior of my app (or maybe that's not what you're saying?).

In the case of assert, enabling/disabling assertions doesn't change the behavior of your app, unless you're doing it wrong. The docs clearly say not to do runtime error checking with assertions, and to use them in a way that when they are turned off the functionality of the code is not affected.


Paul

[Rich Hickey]

For the purposes of testing, it seems like Phil and many others are
looking to change the behavior of their app quite substantially.
That's the purpose of the flag. No one will be forced to use it.

It's on topic for 1.2.1 if having such a mechanism lets people move
forward instead.

Rich

[Paul Stadig]

On Thu, Mar 10, 2011 at 1:57 PM, Rich Hickey <richh...@gmail.com> wrote:

For the purposes of testing, it seems like Phil and many others are looking to change the behavior of their app quite substantially. That's the purpose of the flag. No one will be forced to use it.

It's on topic for 1.2.1 if having such a mechanism lets people move forward instead.

Rich

So for the purposes of testing, say I have a dependency I want to mock out, I can't change its code to make its vars dynamic, but I can turn on this flag, and all of the vars become dynamic, thus allowing me to mock my dependency. Can't I accomplish the same thing by changing my test to use with-refes instead of binding?

The tougher problem (and barrier to moving forward) seems to be to be a dependency that expects to dynamically bind a var at runtime, in production, without this flag turned on. I can't change that code, and the behavior of vars has changed from 1.2 to 1.3. Certainly I could run with the flag turned on in production. It's a kind of 1.2 "compatibility" mode. Perhaps that's what you're suggesting.

Secondly, say we have this runtime flag. We can then deploy our app on 1.3-alpha4 with the flag turned on? Presumably the alpha label is distracting to people, because its not a matter of stability, so pushing that aside. I guess that's better than riding snapshots, since we have the versioned release to build and deploy against. So maybe its not a problem that the "final" 1.3 release isn't out for some weeks or months.

My initial thought with a 1.2.1 release was there are fixes that currently exist, they're done and fixed, and there is no workaround available in user code, and 1.3 may or may not be around the corner, and these are not large hairy fixes. It seems like a simple idea to just cherry-pick them to the 1.2 branch and cut a low risk release. Not that these things don't need to be talked about, but I honestly imagined that the release could have been done and done by now.


Paul

[Phil Hagelberg]

On Thu, Mar 10, 2011 at 11:32 AM, Paul Stadig <pa...@stadig.name> wrote:
> The tougher problem (and barrier to moving forward) seems to be to be a
> dependency that expects to dynamically bind a var at runtime, in production,
> without this flag turned on. I can't change that code, and the behavior of
> vars has changed from 1.2 to 1.3. Certainly I could run with the flag turned
> on in production. It's a kind of 1.2 "compatibility" mode. Perhaps that's
> what you're suggesting.

Yeah, I think having a flag like that turned on for test-only
increases the distance between the behaviour of the code during test
vs production. Of course, "how do I know my tests are accurately
reflecting production" is a question that can never be satisfactorily
answered (Out of the Tarpit &c), but I'd like to avoid solutions that
could increase this in ways that may be hard to verify.

Anyhow, avoiding with-redefs in the test suite is mostly about being
able to parallelize them, but if we bite the bullet and replace all
our bindings with with-redefs, there are still pretty substantial
failures, the causes of which aren't immediately apparent. We'll want
to investigate these at some point down the line, but given the fact
that the fixes we need to Clojure 1.2 are well-understood and obvious,
that's what I'd prefer at this point.

-Phil

[Paul Stadig]

If its helpful at all, I created updated the 1.2.x branch in my fork of clojure with the keyword intern patch and the multimethod patch applied (the two I've been pushing for). I built it and ran it against our code base at Sonian without any test failures.

https://github.com/pjstadig/clojure/tree/1.2.x


Paul

[Rich Hickey]

On Mar 10, 2011, at 6:14 PM, Phil Hagelberg wrote:

> On Thu, Mar 10, 2011 at 11:32 AM, Paul Stadig <pa...@stadig.name>
> wrote:
>> The tougher problem (and barrier to moving forward) seems to be to
>> be a
>> dependency that expects to dynamically bind a var at runtime, in
>> production,
>> without this flag turned on. I can't change that code, and the
>> behavior of
>> vars has changed from 1.2 to 1.3. Certainly I could run with the
>> flag turned
>> on in production. It's a kind of 1.2 "compatibility" mode. Perhaps
>> that's
>> what you're suggesting.
>
> Yeah, I think having a flag like that turned on for test-only
> increases the distance between the behaviour of the code during test
> vs production.

What are you using binding for during testing in the first place then?

Rich

[Phil Hagelberg]

On Thu, Mar 10, 2011 at 4:47 PM, Rich Hickey <richh...@gmail.com> wrote:
>> Yeah, I think having a flag like that turned on for test-only
>> increases the distance between the behaviour of the code during test
>> vs production.
>
> What are you using binding for during testing in the first place then?

Right--I meant that we use binding right now for very focused
behaviour differences that we are explicitly opting-in to, whereas
dynamic-in-test-only seems to have a wider scope. Perhaps it could be
shown to not have a big impact on test correctness; that was just my
initial reaction.

The failures in my initial attempts to run our tests against 1.3 are
not clearly due to dynamic binding changes, so I'm not sure whether
this relaxed-rebinding flag would address our needs specifically, but
it may be worth pursuing regardless.

-Phil

[Paul Stadig]

I have merged the other two patches mentioned on http://dev.clojure.org/display/design/Release+1.2.1. The only conflict was from the circular detection patch which was modifying a src/script/run_tests.clj file that does not exist on the 1.2.x branch, and I think can be safely ignored. All of the other patches applied cleanly.

The multimethod fix isn't officially approved and merged to master yet, so that may be something to consider.

The Clojure tests ran without any failures, and I ran the build against Sonian's code base without any failures. I don't think we have an deftypes or defprotocols that have dashes in their namespaces, so CLJ-432 probably wouldn't have affected our test suite anyway.

I'm not sure what this tells us exactly since these bugfixes are for errors that happen under certain conditions, and if those conditions had been true of our test suite it wouldn't have run successfully on 1.2.0, but anyway it shows that under normal non-error usage 1.2.1 seems to be fine. What other assurances should we get? Should we run the clojure-contrib 1.2.0 test suite against 1.2.1?

I'm happy to throw away this branch if we decide that the Right Thing to do is move to a 1.3-alpha4 release. It was very simple to create this branch. I really just think this is a low risk release and shouldn't be a big deal.

Perhaps this will reach you in time to consider this all during your meeting today.


Paul

[Stuart Halloway]

> I'm happy to throw away this branch if we decide that the Right Thing to do is move to a 1.3-alpha4 release. It was very simple to create this branch. I really just think this is a low risk release and shouldn't be a big deal.

I would like to cut another 1.3 alpha today, and Aaron is working on creating some new top level repos for common contribs.

If there was a short list of issues keeping you off 1.3 I would much rather fix those than start the precedent of branching the past. If, after enumerating and discussing those issues, you still need a 1.2.1 I am willing to make it.

Stu

[Paul Stadig]

*Oof* Ok. I guess I can't argue with you since I already said that I would be willing to try to move to 1.3. :)  It seems to me "there isn't a final 1.3 release" and "I'd prefer to not to have to change my code for some minor bugfixes" are reason enough combined with "people cut bugfix releases all the time, it's not a big deal."

However, I'm willing to look into what it would take to move to a 1.3-alpha release, and report back the results.


Paul

[Justin Balthrop]

Another option is just to create your own 1.2.1 release, release it to clojars and start using it. That's what we had to do for the Keyword intern bug, as Clojure was unusable for us without that fix.

http://clojars.org/org.clojars.lancepantz/clojure

Justin

[Paul Stadig]

On Fri, Mar 11, 2011 at 10:38 AM, Justin Balthrop <jus...@justinbalthrop.com> wrote:

Another option is just to create your own 1.2.1 release, release it to clojars and start using it. That's what we had to do for the Keyword intern bug, as Clojure was unusable for us without that fix.

http://clojars.org/org.clojars.lancepantz/clojure

Justin

Oh yes! I'm aware of that option, but was stopping short of doing it. I thought it would be better for the community to have a release than for everyone to make their own.


Paul

[Justin Balthrop]

Agreed. We would definitely upgrade to the official 1.2.1 if there was one.

Justin

[Paul Stadig]

On Fri, Mar 11, 2011 at 11:34 AM, Justin Balthrop <jus...@justinbalthrop.com> wrote:

Agreed. We would definitely upgrade to the official 1.2.1 if there was one.

Justin

So you should have maybe spoken up as someone who needs a 1.2.1 release? If the fact is that there are people out there who need these bugfixes, and have resorted to making their own build of Clojure, then that's worth weighing into this whole situation.


Paul

[Justin Balthrop]

Yeah, I was a little late to this thread, but you can count Geni with Sonian on the side of wanting a 1.2.1 bugfix release.

We thought about switching to 1.3, but we rely on too many libraries that haven't switched yet and decided that applying the patch we need would be easier and safer for now, especially with a huge release on the horizon.

Justin

[Stuart Halloway]

Ticket and patch created: http://dev.clojure.org/jira/browse/CLJ-754.

Please review and make sure that this patch will create a 1.2.1 you can be happy with!

Stu

Stuart Halloway
Clojure/core
http://clojure.com

[Phil Hagelberg]

On Fri, Mar 11, 2011 at 11:03 AM, Stuart Halloway
<stuart....@gmail.com> wrote:
> Ticket and patch created: http://dev.clojure.org/jira/browse/CLJ-754.
> Please review and make sure that this patch will create a 1.2.1 you can be
> happy with!

Sonian tests and Leiningen tests all check out with this patch, so I
award it two thumbs up.

Thanks a bunch!

-Phil

[Stuart Halloway]

>> Ticket and patch created: http://dev.clojure.org/jira/browse/CLJ-754.
>> Please review and make sure that this patch will create a 1.2.1 you can be
>> happy with!
>
> Sonian tests and Leiningen tests all check out with this patch, so I
> award it two thumbs up.
>
> Thanks a bunch!
>
> -Phil

Thanks. I just added a new patch including a fix Rich wanted in, if anybody else is testing make sure your grab the later patch.

Stu

[Justin Balthrop]

All tests pass for Geni with the newest patch.

Though I did have to patch Jiraph to use the new java package names for deftype classes. What is the appropriate way to deal with this in libraries? Just move forward and depend on 1.2.1, or maintain two different versions?

Justin

[Phil Hagelberg]

On Fri, Mar 11, 2011 at 11:56 AM, Stuart Halloway
<stuart....@gmail.com> wrote:
> Thanks. I just added a new patch including a fix Rich wanted in, if anybody else is testing make sure your grab the later patch.

All clear on 1.2.1 take 2 as well.

On a related note, the 1.2.0 zip file release had a script/ directory
that contained a number of shell scripts that didn't really work very
well and appear to have been included by accident. We should ensure
that those don't get included in 1.2.1's zip.

-Phil

[Stuart Halloway]

On a related note, the 1.2.0 zip file release had a script/ directory
that contained a number of shell scripts that didn't really work very
well and appear to have been included by accident. We should ensure
that those don't get included in 1.2.1's zip.

That was mostly my fault, and they won't.

Thanks,

[Stuart Halloway]

The maven artifacts are deployed at http://build.clojure.org/releases/org/clojure/clojure/1.2.1. Please let me know they look good before we make a broader announcement.

Note that these artifacts must be pushed by hand, using a crufty old process that is no longer in play on the master branch. If the process seems dumb that's because it is. :-)

Stu

[Andy Fingerhut]

I used 1.2.1 to run all of the latest benchmark programs, and compared the run times against 1.2. All of them were within +/- 2% when measured by "user + system CPU time", "elapsed time", and within a few percent on maximum resident set size and total memory GCed (those measurements tend to be more jumpy from one run to the next even for the same version of Clojure, with no change in the program).

One of the programs that used to run just fine on 1.2 with a particular max heap size now exhausts the heap space, not all of the time, but a noticeable fraction of the time. I'll look into that one a little bit more, but I suspect the max heap size I'm giving it might be right on the edge for 1.2, and is a bit too small for 1.2.1.

Andy

[Andy Fingerhut]

OK, false alarm on the memory use of that one program. I ran it many times with several different max heap sizes for both 1.2 and 1.2.1, and the results were very similar between the two Clojure versions. I just got unlucky before in the few runs I had made where 1.2.1 ran out of memory. 1.2 can run out of memory at the same max heap size, too. The program isn't deterministic in its memory usage, because of a pmap call.

Andy

[Stuart Halloway]

No worries about the false alarm -- I am thrilled that you are putting 1.2.1 through its paces.

Stu

[Alex Miller]

In trying to test our Revelytix code with 1.2.1 I'm seeing a number of
test files that now fail to compile with 1.2.1 and instead throw
ClassNotFoundException on a defrecord type. I've tracked this down to
a consequence of the deftype name-munging change for
http://dev.clojure.org/jira/browse/CLJ-432.

I see this happening when I have a ns with a "-" in it, I create a
record in that ns, then later in that same ns check the type of a
record with class. Before those class names had -'s in them (which
looks righter from a Clojure perspective) but now they will have _'s.
This makes sense from the perspective of the patch above but is
unfortunate from needing to understand the clojure/java behavior when
referring to record types.

A variant of this same issue is in the patch for CLJ-432 in the change
to test/clojure/test_clojure/protocols.clj (that test was presumably
broken in this same way for protocol names).

Example:

(ns my.rec-test
(:use [clojure.test]))

(defrecord Foo [a])

(deftest test-rec
;; 1.2.0 should use my.rec-test.Foo
;; 1.2.1 should use my.rec_test.Foo
(is (= my.rec-test.Foo (class (Foo. 1)))))

I'm not necessarily requesting anything be done here. We can make the
necessary changes in our code to move to 1.2.1 but I will note that
none of our projects actually compiled after going to 1.2.1 which was
initially alarming so take from that what you will.

Alex

[Phil Hagelberg]

On Fri, Mar 11, 2011 at 6:22 PM, Stuart Halloway
<stuart....@gmail.com> wrote:
> The maven artifacts are deployed at http://build.clojure.org/releases/org/clojure/clojure/1.2.1. Please let me know they look good before we make a broader announcement.

Are we still evaluating this? I am thinking of doing a Leiningen 1.5.0
release soon that would default to new projects using 1.2.1, but I
will hold off if the problem Alex mentioned needs further
investigation.

-Phil

[Sean Corfield]

On Fri, Mar 11, 2011 at 6:22 PM, Stuart Halloway
<stuart....@gmail.com> wrote:

> The maven artifacts are deployed at http://build.clojure.org/releases/org/clojure/clojure/1.2.1. Please let me know they look good before we make a broader announcement.

Will clojure-contrib rev to 1.2.1 for consistency with the official
release of clojure 1.2.1? Or will users just have to get used to
seeing different versions for these dependencies in their project.clj
file? :)

:dependencies [[org.clojure/clojure "1.2.1"]
[org.clojure/clojure-contrib "1.2.0"]

Sorry if I seem to keep on about contrib version numbering but keeping
track of which is the right contrib version to use with any given
clojure version can be a bit frustrating. I switched one of our
projects up to 1.3.0-alpha6 after I saw the mention of that but then
had to futz around to establish that contrib/sql was only at
1.3.0-alpha4 :)

I understand that this prior 1:1 correspondence will be completely
broken, at least for a while, with the new contrib libraries
(tools.logging at 0.1.1 yes? not yet available via maven repos?) but
is the plan to unify the version numbers again - including new contrib
- or to reset expectations completely? If the latter, how will users
easily keep track of the corresponding / correct / latest versions of
contrib pieces?
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
Railo Technologies, Inc. -- http://getrailo.com/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Stuart Sierra]

All "new" contrib libraries will be released as .jar files containing .clj sources only, at least until binary compatibility issues across different Clojure versions are sorted out.  Contrib libraries will be have versioning and releases independent of Clojure and should work with any recent Clojure version.

New contrib libraries will be released to oss.sonatype.org and sync'ed to Maven Central.  Logging, JSON, nREPL, JMX, and finger-tree have all been released: http://repo2.maven.org/maven2/org/clojure/

"Old" clojure-contrib, the monolithic one, is deprecated as of now.  No new development is happening there -- the first step in continuing development of any clojure-contrib library is to make it a "new" contrib.  The 1.2.0 clojure-contrib release has been manually uploaded to Maven Central, in both AOT-compiled and source-only forms.  The source-only form works with Clojure 1.3.0-alpha*.

I do not plan on a 1.2.1 clojure-contrib release unless there is a compelling need for it.

We (Clojure/core) have been considering some kind of "batteries included" release with all the latest contrib libraries.  This might take the form of a combined jar file or just a project template. 

-Stuart Sierra

clojure.com

[Sean Corfield]

On Sat, Mar 19, 2011 at 1:40 PM, Stuart Sierra
<the.stua...@gmail.com> wrote:
> All "new" contrib libraries will be released as .jar files containing .clj
> sources only, at least until binary compatibility issues across different
> Clojure versions are sorted out.

Good to know. Thanx.

> New contrib libraries will be released to oss.sonatype.org and sync'ed to
> Maven Central.  Logging, JSON, nREPL, JMX, and finger-tree have all been
> released: http://repo2.maven.org/maven2/org/clojure/

OK. I wasn't sure where to look for the authoritative release versions.

For my own sanity, I created a page on my site that scans that repo
and shows the latest and earlier versions of the various Clojure
libraries:

http://corfield.org/clj/index.cfm

It caches the results for an hour - I figured that was "recent
enough". Is it worth adding all the Clojure contrib modules too? Or
does no one else find this hard to keep track of? :)

> "Old" clojure-contrib, the monolithic one, is deprecated as of now.  No new
> development is happening there -- the first step in continuing development
> of any clojure-contrib library is to make it a "new" contrib.

So, for a while, at least, Clojure 1.3.0 programs might be a mix of
"old" contrib/foo 1.3.0 and "new" contrib pieces at different
versions? I guess I can phrase that question another way: I'm
currently using Clojure 1.3.0-alpha6 and contrib/sql 1.3.0-alpha4 -
when Clojure 1.3.0 goes final, where should I expect to find what is
currently contrib/sql 1.3.0-*? Will it become/stay clojure.contrib/sql
"1.3.0" or clojure.core.sql "1.3.0" or...?

I guess I just don't have a handle on plans for the current contrib
pieces and I haven't seen a roadmap for them (or I missed the
discussion / documentation of that).

[Stuart Sierra]

It's reasonable to be confused, since we don't completely have a handle on it ourselves.  We would like to avoid having to make any more releases of "old" clojure-contrib.  Once we feel like we've ironed out the process for creating "new" contrib libraries we will solicit volunteers to create "new" libraries out of stuff in "old" contrib.

Most of the stuff in "old" contrib is out-dated and unmaintained; these libraries will not survive the changeover to "new" contrib.  SQL is almost certainly going to become a "new" contrib library, it just hasn't happened yet.

-S

[Chas Emerick]

On Mar 19, 2011, at 6:28 PM, Sean Corfield wrote:

>> New contrib libraries will be released to oss.sonatype.org and sync'ed to
>> Maven Central. Logging, JSON, nREPL, JMX, and finger-tree have all been
>> released: http://repo2.maven.org/maven2/org/clojure/
>
> OK. I wasn't sure where to look for the authoritative release versions.
>
> For my own sanity, I created a page on my site that scans that repo
> and shows the latest and earlier versions of the various Clojure
> libraries:
>
> http://corfield.org/clj/index.cfm

Much better to just use the official maven central search engine:

http://mavencentral.sonatype.com/#search|ga|1|clojure

- Chas

[Paul Stadig]

This weekend, we just had another keyword intern kill some work on one of our nodes. Kind of a drag!

We still waiting on something to pull the trigger here? I say push the artifacts out!


Paul

[Stuart Halloway]

This weekend, we just had another keyword intern kill some work on one of our nodes. Kind of a drag!

We still waiting on something to pull the trigger here? I say push the artifacts out!


Paul

They are pushed, just not announced: The maven artifacts are deployed at http://build.clojure.org/releases/org/clojure/clojure/1.2.1.  

Prior to the 1.3 line there is no automatic push to maven central. If it is important to do so, and if somebody knows the mojo to push them to maven central, that's fine to do.

Stu

[Paul Stadig]

Sweet! Thanks!

Paul

[Chas Emerick]

Anyone in Clojure/core with access to the org.clojure group in the OSS repo can upload the artifact + pom through the nexus admin site.

- Chas

[Stuart Sierra]

Ok, I will take this as a task for this Friday.

-S

[Phil Hagelberg]

> They are pushed, just not announced: The maven artifacts are deployed
> at http://build.clojure.org/releases/org/clojure/clojure/1.2.1.

So it sounds like the announcement is waiting on the push to central
rather than any changes that may be made to 1.2.1 itself? If so it
should be OK to make Leiningen use this version since it's going to be
getting it from build.clojure.org anyway, right?

-Phil

[Stuart Halloway]

Yes. We aren't changing anything, barring unforeseen unpleasantness.

Stu

[Sean Corfield]

On Mon, Mar 21, 2011 at 4:32 AM, Chas Emerick <ceme...@snowtide.com> wrote:
> Much better to just use the official maven central search engine:
>
> http://mavencentral.sonatype.com/#search|ga|1|clojure

"Much better" depends on your needs. That lists things I don't want to
see and doesn't show old versions at a glance (which I do want to
see). Nor does it list the contrib modules. As I said, that page on my
site is mostly for my own sanity - if anyone else thinks it's useful,
great, otherwise it's no big deal :)

--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

World Singles, LLC. -- http://worldsingles.com/

Railo Technologies, Inc. -- http://www.getrailo.com/