Semantic versioning
raimohanska opened this issue · comments
I've been releasing these 0.7.N versions for years now. I suggest we rebrand the current version as 1.0 and start doing decent semantic versioning. How about that?
Hi! So, seems that 0.8 branch will never be merged into master ?
Speaking frankly, I'm very glad that 1.0 will be based on time-proven 0.7.x !
Cheers!
Yeah, that branch is outdated. It has proven hard to decide what 0.8 would actually include. There have been a bunch of breaking changes that we've considered implementing but never actually done it.
I've felt that when we include breaking changes, we should do it once and for good, so that we don't break people's code all the time. On the other hand, after 1.0 we can use semantic versioning properly so your app won't break randomly when breaking changes are introduced.
Up to the current version (0.7.94) we've kept Bacon.js very much backward-compatible and I think this could be version 1.0.
I've felt that when we include breaking changes, we should do it once and for good, so that we don't break people's code all the time.
One approach that other big JS projects (Node, React, Angular) have adopted is releasing new major versions on a regular, scheduled basis (about once a year for the projects I listed), but making each major version only introduce a few breaking changes.
The major advantage of this approach is that the migration instructions from one major version to another are minimal and don't require too much time/effort from the users. That makes it more likely that programmers will jump onto the new version, and then you don't have to face the major user issues that, for example, plagued the AngularJS 1 to Angular 2 change.
IMO, the next major Bacon.js could have some speed improvements from Kefir (or inspired by).
So, if one does remember node / io.js codebase split and latter merge that thing could be theoretically possible. )
Just released 1.0.0