>> While I think we should indeed soon release 3.2, I believe that it is >> not so urgent that it can't wait for a few more useful changes, >> especially since we do provide backward compatibility functions for >> the old API. So I propose we release a 3.1.5 for now, and do a few >> more changes before we actually cut a 3.2. > > I wasn't clear: I don't mean that we need to do a 3.2 release at this > very moment, just that these changes are not fully compatible, so are > worthy of a "greater than patch level" release. > Well, we do provide a backward compatible API; but it's true that the behavior on Windows has slightly changed.
On the other hand, we have accumulated enough bug fixes and features since last October, including support for a new implementation (clasp) to warrant a release soon. Release numbers are not a scarce resource, so if you believe this requires a 3.2 release now, that just means that the further changes I'd like will have to be for a 3.3 release. > On the other hand, maybe we need to have 3.2.0.1 be the next thing we > push, and call it a release candidate. It may be that the release will > have to be 3.2.1, but I could live with that. > That's how we did the 3.1 release: pre-releases as 3.1.0.x, and release as 3.1.1. It seems to have worked out well — well except for immediately followeing it with a 3.1.2 for a bug fix :-(. > What do firm believers in semantic versioning do about this? Just > always have their release be x.y.z when they want x.y, so that they can > have a release candidate? Or do they do something like x.y.rcz? That > would require a change to VERSION-SATISFIES... > We could specially parse rc as "-1", "beta" as "-2", "alpha" as -3, etc, but that sounds like dubious over-engineering to me. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Director is a misnomer. You're a hoper. You put all these people together and you hope it all works out. — Frank Oz, director of "Dirty Rotten Scoundrels"
