I agree these changes are for the best. Not announcing breaking changes is "not optimal" as it were, but we should solve the general problem, rather than this specific instance
In a world with codeq, the capability exists to detect breaking changes. Both by library authors, and by their consumers. The key of course is to make this easy. A centralized, pre-imported codeq datomic database, and associated lein tasks, would be one way to do that. On Thu, Oct 25, 2012 at 11:08 AM, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > I am not opposed to having a shim to support an API compatible with older > releases. It's not even particularly difficult: > > https://gist.github.com/3950124 > > I certainly did not anticipate this release causing significant problems for > application or library developers, and if it did then I apologize. > > However, I will stand by the decision to update the API. data.json 0.1.x > suffered from what I consider, in retrospect, to be poor design decisions. > Those were decisions I made over two years ago in a hasty effort to please > too many people who had conflicting goals: > > > - Converting field names to keywords by default can create invalid > keywords. > > - Keywordization is controlled by a bare boolean argument with little > indication of its function. > > - Inconsistent styles of optional arguments: read-json and write-json take > booleans as bare arguments, json-str and print-json use keyword-value pairs. > > - Parsing a string and parsing from a stream -- two very different > operations -- are conflated in a single function. > > - Functions are not consistently named: json-str, read-json, write-json > > - Function names repeat the name of the library, rather than using > namespaces. > > > It was impossible to solve some of these problems without introducing > breaking changes. > > Looking at the Clojure Library Coding Standards[1], data.json 0.2.0 does a > better job at "Use good names" and "Unroll optional named arguments." It > fails at "Java's commitment to not break existing code." In this instance, I > believe the tradeoff is worthwhile because the new API can be more easily > extended with additional arguments. This also opened up a place to add new > features such as customizable conversion functions, the > most-commonly-requested feature for this library. > > Per Rich's directive[2], I cannot yet make a 1.0.0 release. Therefore, 0.1.3 > to 0.2.0 is the largest version bump I can make and the best indication I > can give of breaking changes. I hope that these improvements to the API > bring this library closer to a 1.0.0-ready state. > > I'm not trying to make anyone's life more difficult, just trying to provide > useful tools. > > -S > > > [1]: http://dev.clojure.org/display/design/Library+Coding+Standards > [2]: http://dev.clojure.org/display/design/Contrib+1.0.0+Releases > > > > -- > 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 -- 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
