Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
In an open source framework deprecated APIs were removed during the beta phase on the road to a new major version. Now users request to restore some deprecated APIs because it breaks compatibility. For me, beta stands for "Use at your own risk".
As you have mentioned, your users are currently complaining on the road to a new major version.
Isn't it expected that due to a major version bump the API may change?
Either you don't make backwards-incompatible changes in the API, or you would be doing that in a major version bump. If you aren't doing it in a major version bump, where would you be doing that? Unless you do it in a minor version bump, which is obviously even more improper. So basically, there is nowhere better to do it apart from a major version bump, right?
API changes are or are not expected in a major version change, depending on your system of API versioning. It seems that in your case, it is. This is your own decision, although common. Unless you are totally not planning to make backwards-incompatible changes.
Is it "uncommon" to change the API in a beta phase?
The beta phase, according to the usage specified in your post, can be assumed as "previews of a release candidate", and "not finalized". If you are having backwards-incompatible changes, you should release them as soon as possible in order to give more time to the users of your API, say, to fix the compatibility problems. Of course, you won't do that in releases before the version bump because of obvious reasons (you have already marked @Deprecated in earlier versions! Why did people still compile code despite the warnings?). Since you are going to make these changes in the release candidate anyway, why leave them later? Moreover, technically your beta versions are already major-version-bumped.
This question can also be understood as API changes betwteen beta releases of the same version. As long as you are going to add these changes in the major version bump, it is not a problem. After all, during the beta phase, the API changes can be considered as "not yet finished changing".
Finally, always remember: every single change breaks backwards compatibility.
xkcd: Workflow -- There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.
To cite from Semantic Versioning 2.0.0
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Hence, if you talking of a beta as the 0.x.x version then yes. Anyway, considering section 8
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.
and section 10
A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
If you are talking of a beta as an unstable version of a new release, a non backward-compatible change in the public API would be 'legal' if you increased the major version, but not afterwards.
I believe that many projects use semantic versioning or a similar versioning scheme. Anyway, anything said does only hold true for semantic versioning. If you are following your own versioning scheme you are free to do anything you like, but if you keep breaking the public API people using you library could get frustrated and stop using it, so you should consider keeping all changes in a development branch and only release a beta of a new version if you are sure that there won't be any more changes in the public API.
