+1 We were in production in Jan 2009 before Clojure 1.0 came out. We face the issue of un-rooting ourselves from the "old" contrib stuff.
After analysis, 97% of the stuff we need from the "old" contrib is now available in 1.3 as separate libs. The only thing we would like to keep is the trace module by Stuart Sierra and we volunteer to move it to 1.3 and maintain it. Nothing to panic about here. A new release always involves some code rework anyway. Luc P On Sat, 10 Sep 2011 12:31:14 -0700 Sean Corfield <seancorfi...@gmail.com> wrote: > On Sat, Sep 10, 2011 at 9:46 AM, Jan Rychter <jrych...@gmail.com> > wrote: > > If you use Clojure to build an application that you subsequently > > launch and maintain, it is pretty much a given that you use contrib. > > Lots of it, in fact. > > I think that depends on when you started building stuff with Clojure. > I get the impression quite a bit of old contrib grew up to provide > functionality not in Clojure's core and I see quite a few pieces of > old contrib that are explicitly deprecated because functions moved to > Clojure 1.2 (c.c.string, for example, mostly moved to clojure.string > long before Clojure 1.3 got under way). I suspect that folks who > started with Clojure long ago and are relying heavily on old contrib, > are probably relying on those old deprecated namespaces and functions > and have simply avoided updating their code to use the newer, > supported namespaces. I think the break in contrib coming with 1.3 > will be good for the Clojure ecosystem overall because it will force a > lot of folks to clean up their code :) > > As noted in another one of my comments in this thread, World Singles > started with Clojure 1.2 but switched to Clojure 1.3 early on and so > we've essentially not been allowed to depend on that old, unsupported > contrib code which I view as a big positive for us (as well as getting > the performance boost of the updated numerics in Clojure 1.3). > > One of the things World Singles needed early on was > clojure.contrib.sql so I pushed for that to be migrated and have ended > up being the maintainer now. If you can't find an author to migrate > and maintain an old contrib library, another option is for you to > volunteer to do that work and then you have the added benefit of being > able to enhance the library to better suit your needs (e.g., I added > the ability to return generated keys from insert operations in > clojure.java.jdbc). > > > importantly, I worry that I won't be able to take advantage of > > Clojure 1.3 in any of my applications anytime soon. > > A definite possibility - but changing your code to not rely on > outdated, unsupported libraries would have benefit to you in the long > run, yes? > > > I think contrib modularization should either be carried all the way > > in time for 1.3, or stopped altogether (meaning I could continue to > > use the same old monolithic contrib code with Clojure 1.3). > > Sorry, that ship done sailed a while back. I don't know how much work > it would be to make the modular contrib work on Clojure 1.3 (work > stopped on contrib around 1.3.0 Alpha 4) and given the number of > library authors who've stepped up to modernize and maintain new > contrib versions of old library modules, I can't imagine who'd put in > that work (to make old, unsupported code run on Clojure 1.3). -- Luc P. ================ The rabid Muppet -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
