[PROPOSAL] Add new branch for current 1.* releases

[mfn]

I would like to propose to add a v1 branch, forking off from current master, effectively putting the current 1.* release cycle a bit to rest.

What I mean with "to rest":

• major new development should happen in master for a v2 release (refactoring, clean up)
  • as such I've added a "blocked" label to all the (mine 😉) PRs as they should not be merged into the v1 release cycle
• only essential bugfixes (TBD what this means) should go to v1
• fixes going into v1 are merged into master, but changes to master are not going to be merged back

The reason I'm proposing this is that, with all the refactoring, it needs some time to get it stable enough.

Although we've tests and they're green, upon closer looking I'm always finding issues which are not covered in any test.

I do plan to write tests to increase the coverage, but at the same time would also like to tackle other issues.

I don't want to bring to much instability in the current release cycle and break others people code when they update due to the insufficient test coverage.

The idea would also that, at some later point when a v2 is made, this project would follow SemVer (future discussion about viability) and eventually the v1 can be removed when we deem the test suite coverage is good enough.

How does that sound?

[rebing]

Sounds good! So basically we should currently make v1 and v2 branches and add all updates to v2, but only bug fixes to v1?

[mfn]

In theory, yes.

I woldn't be too strict about new features if they can be easily be done but would rather love to concentrate on the v2; whatever exactly it may become.

[rebing]

Agreed, let's concentrate on v2 and only update the current version when critical

[mfn]

There's now a v1 branch creates from master 9b75586