Hi,
The original plan was to introduce all backwards incompatible changes on the roadmap all at once, and only then make a first official release. However this turns out to be very impractical and slows down the development process. Lately I'm also receiving requests from distribution packagers (Debian in particular) to make some real releases.
Therefore, I propose the following intermediate strategy. We start making early releases with version numbers 0.x.y. Whenever a backwards incompatible change is introduced, the number x is increased. For fully backwards compatible changes, only the number y is increased. This would allow me to introduce new changes incrementally. I'm aware this won't be perfect for applications, but at least you can require a specific version, and/or support multiple versions with conditional compilation.
Once the api is declared fully stable, we move on to version 1.0.0 and provide full backwards compatibility from there on.
Would this be an acceptable solution for you? Feedback is always welcome!
Jef
Am 06.04.2012 13:54, schrieb Jef Driesen:
Therefore, I propose the following intermediate strategy. We start making early releases with version numbers 0.x.y. Whenever a backwards incompatible change is introduced, the number x is increased. For fully backwards compatible changes, only the number y is increased. This would allow me to introduce new changes incrementally. I'm aware this won't be perfect for applications, but at least you can require a specific version, and/or support multiple versions with conditional compilation.
Once the api is declared fully stable, we move on to version 1.0.0 and provide full backwards compatibility from there on.
Would this be an acceptable solution for you? Feedback is always welcome!
I would prefer small steps while keeping a working library at all times. Doing a too big step will delay the release of new features unnecessary. my 5 cents.
-
Björn Spruck -
Jef Driesen