BuildCraft|Core

BuildCraft|Core

7M Downloads

Breaking changes and versioning system.

Kubuxu opened this issue ยท 7 comments

commented

BuildCraft was very strict about versioning system. Breaking changes were only introduced in new major releases. As there are breaking changes introduced in source tree right now, we should consider creating 7.0.x branch and reverting those changes from 6.x.

commented

@Kubuxu - breaking changes were introduced both in the API and in blueprints in 6.1 already months ago, this is absolutely normal.

And by "breaking", I mean "complicated" - migration code will be available.

commented

It was my perception of past BuildCraft's API versioning. I always thought that BC is using Semantic System.

commented

@Kubuxu - notice, however, that BuildCraft 6.1 is still in beta and thus subject to change.

commented

Yup. But, if we want to follow Semantic, 6 was released so 6.x should only contain additions into API ot deprecations marking.

commented

Assuming the intentions is to use Semantic Versioning @Kubuxu is right.

Minor versions X.Y should not include backwards incompatible changes, this is reserved for major versions X.0

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

It may be that it's been decided not to follow this conversion any longer, but this is how BC used to do it, and that is the semantic way.

I think it's a completely fair discussion to have, weather anyone cares about this system being followed any longer, or not.

commented

@Hanse00 - The problem is, we would have gone to 20.0.0 fairly quickly, as beta and alpha versions of BuildCraft 6.0 and 6.1 alike broke APIs fairly often.

I might come back to using SemVer properly at 7.x, however, incompatible API changes in Java are very easy to make.

commented

@asiekierka Indeed alpha and beta versions should likely be exempt from this scheme, as long as any API breaking changes in there do not get added to the release version until another major version.

I'm just saying that that's how SemVer works, it's not necessary to stick to it.
As long as we're all agreed on the fact that it's not currently being followed, so there's no confusion involved.

Just wanted to give kudos to @Kubuxu, for technically being correct about the system not being followed.