The choice boils down to whether or not you want to follow Semantic Versioning [1]. Apache (APR) [2], Eclipse [3], and OSGi [4] all seem to have equivalent policies. Personally, I think it's a perfectly logical approach to increment the major version number for any backwards incompatible change.
Python officially has a more relaxed interpretation [5]. My understanding is that in practice the Python community was very concerned about backwards compatibility among the late 2.x releases because 3.0 was going to introduce big changes. > Python versions are numbered A.B.C or A.B. A is the major version number – it > is only incremented for really major changes in the language. B is the minor > version number, incremented for less earth-shattering changes. C is the > micro-level – it is incremented for each bugfix release. The Wikipedia article on software versioning [6] covers some other concerns such as marketing. I guess that takes into account the idea that "2.0" should be a major improvement. As I said, I personally like the concept of semantic versioning. If Rich wants to do something else, I can live with an incompatible 1.3. In any case, it would be useful for the Clojure Core team to document the Clojure version policy. [1] http://semver.org [2] http://apr.apache.org/versioning.html [3] http://wiki.eclipse.org/index.php/Version_Numbering [4] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf [5] http://docs.python.org/faq/general.html#how-does-the-python-version-numbering-scheme-work [6] http://en.wikipedia.org/wiki/Software_versioning -- 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
