Giving version numbers that make clear when you're breaking backward compatibility

Question

I've been working on my open source project for about 6 months, and I want to release it officially soon. The thing is, I'm quite sure that in the near future I will want to change my project in a way that will break backward compatibility, probably multiple times. (My code is a framework in which people have to build code according to a certain API.)

What would be a good way to mark this project as being in a state where backwards-compatibility might be broken soon?

I see that some projects, like Python and Django, have the rule that backward compatibility is maintained between versions which share the same "big version number." (i.e. the number immediately left to the dot.)

I've been thinking to adopt this rule, but it would be kind of weird, if next week I release version 0.1, and then I couldn't break backward compatibility until I release version 1.

Any ideas?

Answer 1

Why don't you go ahead and release version 1. Continue to update that version without breaking backwards compatibility, and then release version 2 separately which does so.

Either way, I cringe every time I hear backwards compatibility will not be met eventually, but that's more of a personal opinion.

Answer 2

You got it backwards. You increase the major number when you break backwards compatibility, not when you run out of minor numbers. Though at 0.x you might also consider the software too immature and unstable to even bother maintaining compatibility.