Roadmap to stable v1.0.0

[clue]

Let's face it, this project is stable and has been used in production for years

However, we're currently following a v0.X.Y release scheme (http://sentimentalversioning.org/).

We should finally make this explicit and fully adhere to SemVer and release a stable v1.0.0.

To a large extend, a stable v1.0.0 helps making BC breaks more explicit and thus the whole project more reliable from a consumer perspective. This project is actively maintained and has received some major updates in the last weeks and has some major updates planned in the next weeks. Given our current versioning scheme, we'd like to ensure all anticipated BC breaks will be merged before the planned v1.0.0 release.

As such, I've set up a roadmap that enlists only the major changes for each version among with planned release dates towards a stable v1.0.0 release:

v0.4.5 ✅

• Released 2016-11-13
• Major performance improvements
• Infinite read buffer

v0.4.6 ✅

• Released 2017-01-25
• close event semantics
• Standalone Buffer

v0.5.0 ✅

• Released 2017-03-08
• end event semantics
• Strict / explicit event semantics and parameters
• pipe() semantics

v0.6.0 ✅

• Released 2017-03-26
• Read-/Write-only resources
• Enforce non-blocking

v0.7.0 ✅

• Released 2017-05-04
• Reduce public API

v1.0.0

• Planned 2017-?
• No new changes planned, this should merely mark the previous release as "stable"

This ticket aims to serve as a basic overview and does not contain every single change. Please also see the milestone links and the CHANGELOG for more details.

Obviously, this roadmap is subject to change and I'll try to keep it updated as we progress. In order to avoid cluttering this, please keep discussion in this ticket to a minimum and consider reaching out to us through new tickets or Twitter etc.

[kelunik]

@clue For 0.x.y, x is usually considered major and y is minor. Why do you plan three breaking releases in one month? Shouldn't those changes be rather in a single release that's basically a RC of v1.0.0 then?

[clue]

Thanks @kelunik, I think you're raising a very valid concern 👍

From a consumer perspective (somebody who's interested in using a stable v1.0.0) this doesn't really matter, as the v1.0.0 will be released at the same date, irrespective of how many intermediary releases there are. In other words: This roadmap is also set up so that in case you don't want to receive too many breaking changes within the next month, simply wait for the stable v1.0.0 release.

The intermediary v0.x releases are mostly meant for integrators who already build on the existing versions and want a safe upgrade path (the CHANGELOG will list what needs to be changed). These releases DO contain some minor BC breaks, but they're in fact compatible for the most part. Getting these releases out early also helps with updating our other components (such as the HTTP server component), because they require some (but not all) of the changes along the path to the next stable version.

I hope this helps 👍

[kelunik]

@clue The issue with multiple major versions is that version conflicts are way more likely to happen, e.g. if some projects upgrade to ^0.6, but others stay at ^0.4. In some cases ^0.4 || ^0.5 || ^0.6 could be used, but that's not the way people usually do it.

[clue]

@kelunik Yes, version conflicts are more likely to occur if we release more versions with breaking changes, but this is a trade-off we're willing to take in order to ease the upgrade path to the stable v1.0.0 release. As you've rightfully pointed out, most(!) consumers will in fact be able to target multiple major versions in the meantime. Ultimately, this should be resolved either way once the stable v1.0.0 is out in a few weeks anyway 👍

[clue]

Updated now that the v0.5.0 release is out

[clue]

Updated now that the v0.6.0 release is out

[kelunik]

How does #27 fit in the roadmap?