Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap to stable v1.0.0 #67

Closed
clue opened this issue Mar 3, 2017 · 11 comments
Closed

Roadmap to stable v1.0.0 #67

clue opened this issue Mar 3, 2017 · 11 comments

Comments

@clue
Copy link
Member

clue commented Mar 3, 2017

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

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
Copy link

kelunik commented Mar 5, 2017

@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
Copy link
Member Author

clue commented Mar 5, 2017

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
Copy link

kelunik commented Mar 5, 2017

@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
Copy link
Member Author

clue commented Mar 5, 2017

@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
Copy link
Member Author

clue commented Mar 8, 2017

Updated now that the v0.5.0 release is out :shipit:

@clue
Copy link
Member Author

clue commented Mar 26, 2017

Updated now that the v0.6.0 release is out :shipit:

@kelunik
Copy link

kelunik commented Apr 26, 2017

How does #27 fit in the roadmap?

@clue
Copy link
Member Author

clue commented Apr 26, 2017

How does #27 fit in the roadmap?

Afaict there are no plans to get this in for v1.0.0 at the moment. May I ask you to comment on this ticket if you feel this is something that should block this release? 👍

@kelunik
Copy link

kelunik commented Apr 26, 2017

I guess it needs a new method and thus breaks BC otherwise, but not sure.

@clue
Copy link
Member Author

clue commented May 4, 2017

Updated now that the v0.7.0 release is out :shipit:

Unless we find any major blockers, there's hope that this is the last noteworthy release before we get to tag this as v1.0.0 🎉

@clue
Copy link
Member Author

clue commented Jul 11, 2018

The very first stable v1.0.0 release with LTS has just been tagged and released! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants