> I don't want to make a breaking change to the existing API, but in a world > there there is an actively-maintained clojure.java.jdbc I don't think a > resultset function in core makes a lot of sense anyway. > > How about we mark core's resultset-seq as deprecated, with a link to the new > project? Then c.j.j. can do a better resultset-seq, and we will leave the old > fn in core for at least on major release cycle. > > I use resultset-seq everywhere. I don't mind us deprecating it, if a better > version is available elsewhere (but please allow the option of down-casing); > but is there really any need to remove a working function from core? I'm not > keen on introducing gratuitous back-compat issues.
That's why we ask before doing it. :-) The counter-pressures are overall footprint of core, and the potential for library compatibility issues on semi-Java platforms such as android. That said, these issues are hypothetical at this point. > Can we arrange for the deprecated core version to call the c.j.j version, > passing any options to preserve current behaviour as much as possible, and to > fail at runtime if that library is not present? That seems complicated. If removal is going to cause heartburn, we could deprecate without ever removing. Stu Stuart Halloway Clojure/core http://clojure.com -- 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
