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 years and only has some minor 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 quick roadmap that enlists the major upcoming changes with planned release dates towards a stable v1.0.0 release:

v0.4.18 ✅

• Released 2019-07-09
• DNS caching fixes

v1.0.0 ✅

• Released 2019-07-11
• Drop deprecated APIs
• Mark internal APIs as such
• No other 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.

[ghost]

I'd like to add that TCP support should be included in the stable reason for various reasons (secure queries (TLS over TCP), extended queries (larger than 512 bytes), etc.).

This is something I'd like to work on myself (as long as no one is faster), but this is nothing I've planned for intermediate working on, but probably rather something for somewhere Q3 or Q4.

[clue]

@CharlotteDunois I think you're raising an excellent point, so let me try to explain: I agree that this component would not be considered "feature complete" without sending queries over TCP/IP as discussed in #19 and perhaps #80.

The upcoming release should merely mark our APIs as "stable" in the sense that we do not plan to introduce any BC breaks any time soon. This allows consumers of this package to depend on this API for longer term support (LTS).

It's my understanding we should get the LTS release out rather sooner than later and we can always continue working on additional features in future v1.x.0 releases. In fact, I've already prepared the TCP/IP logic and I'm planning to get this shipped the next few weeks

[ghost]

The upcoming release should merely mark our APIs as "stable" in the sense that we do not plan to introduce any BC breaks any time soon. This allows consumers of this package to depend on this API for longer term support (LTS).

I see your point here, but shipping a stable release without a "major feature" would make BC breaks we would've to make (for whatever reason that may be) a lot harder. From a consumer perspective it does not make much difference if we tag the first stable release in one or possibly three month. The component has been used for years like that, so a few weeks or months make no big difference here.

It's my understanding we should get the LTS release out rather sooner than later and we can always continue working on additional features in future v1.x.0 releases. In fact, I've already prepared the TCP/IP logic and I'm planning to get this shipped the next few weeks

Good to hear!

[clue]

@CharlotteDunois I agree that you're making a very valid point from a purely technical perspective. Besides the technical challenges, as a project maintainer my goal is also to communicate how this project can be used and how it can be relied upon. This is we we think our today's 7th anniversary is a perfect timing to get the stable release out today! We've used this chance to clear a lot of the legacy cruft from this package so we can now focus on bringing in some cool features in follow-up releases! 🎉

Resolved via 26c3e7b 🎉