meta: Roadmap to 1.0

[carllerche]

We will be aiming to release Tokio 1.0 by the end of 2020. This issue is a high-level proposal of how to get there.

Impacted crates

The 1.0 release applies to the tokio and tokio-macros crates. The remaining crates, tokio-util and tokio-test will remain at 0.x versions.

Changes

At a high level, Tokio 1.0 will be fairly close to Tokio 0.2. Major differences are:

• Updated I/O traits (io: propose new AsyncRead / AsyncWrite traits #2716, Possibly refactor AsyncBufRead #2428).
• Remove mio from the public API (io: remove mio from the public API. #2728).
• Update to mio 0.7 (tokio: update to mio 0.7 #1190).
• Update to bytes 1.0 (io: depend on bytes 1.0 #3058).
• Move remaining async fns to an intrusive waker style (io: rework I/O driver to use an intrusive linked list for wakers #2779, fs: switch to an intrusive waker style #2927, timer: sleep future should become !Unpin #3028).
• Runtime and #[tokio::main] refinements (rt: Runtime refinements #2720).
• Tweak (or temporarily remove) DelayQueue (issue TBD).
• Misc API tweaks (meta: breaking API changes #2928).

Open questions

There are still some questions that need to be finalized.

• Coordinating with the addition of Stream in std (stream: coordinating Tokio 1.0 with the availability of Stream in std #2870).
• Consider making JoinHandle cancel on drop (Consider making JoinHandle cancel on drop #1830).

Pause on adding new APIs

Focus should be put on work that impacts existing APIs, either by altering them or removing them. Once Tokio 1.0 is released, there will be limited flexibility for altering imperfect APIs. However, it is always possible to add new APIs. There may be cases in which a new API is high value and very straight forward or a reason that adding the API after 1.0 is difficult. In this case, we can explore adding the API before 1.0.

In other words, now is the time to voice complaints about any existing API.

Target release date

Previously, Q3 2020 was mentioned as the target release date. However, productivity this year has been lower than expected due to unforeseen global events. We are now going to target the end of 2020 as a release date.

Intermediate 0.x releases

There will be a Tokio 0.3 release. This release will contain at the very least:

• New I/O traits.
• Runtime tweaks.

There also will be an "0.x" release made as a 1.0 candidate. So, there will be a minimum of two more 0.x releases before 1.0.

1.0 LTS guarantees

Tokio 1.0 will come with LTS guarantees. The proposal is:

• A minimum of 5 years of maintenance.
• A minimum of 3 years before a hypothetical 2.0 release.

The goal of these guarantees is to provide stability to the ecosystem.

MSRV

Tokio 1.0 will need a well-defined "minimum supported Rust version" policy. My proposal is:

• All 1.x Tokio releases will support at least a 6-month old Rust release.
• The MSRV will only be increased on 1.x releases.

Versioning policy

Because Tokio is pre-1.0, features have been released in 0.2.x releases. This will no longer be the case after 1.0.

• 1._.x releases should only contain bug fixes. Besides this, these releases should not substantially change runtime behavior.
• 1.x releases may contain new functionality and larger internal implementation changes.

[seanmonstar]

I assume at 1.0, we shouldn't publicly expose any non-1.0 dependencies. Or, more generally, any exposed dependencies cannot be upgraded to breaking-changes versions without that upgrade being a breaking change in Tokio.

So, since bytes is publicly exposed (the Buf and BufMut) trait, we'd either need to:

• Promote bytes to 1.0.
• Extract Buf and BufMut to some other crate that can be released at 1.0.

[hawkw]

• Extract Buf and BufMut to some other crate that can be released at 1.0.

This seems like potentially the better option, since it allows us to continue versioning bytes more aggressively? It might also encourage more experimentation with other implementations of Buf/BufMut, which seems beneficial to the ecosystem.

[carllerche]

@seanmonstar @hawkw a third option is to "hide" Buf and BufMut from the Tokio public API for the initial 1.0 release. I added that to the original issue and will write up my thoughts on it.

[seanmonstar]

It's probably also worth being sure that tokio-compat makes it real easy to try out each of these releases. The amount of refactoring needed from now on should be very low, but if it's possible to make it a cinch to try out 0.3 and 0.4, we can get more testing before solidifying our unseen mistakes forever.

[LucioFranco]

Remove mio from the public API (issue TBD).

Do we have any idea of how far mio is from 1.0?

Another question, what is our general game plan for io_uring? Do we want to go the route of a separate crate so that we can 1.0 and deal with it later? Or will it be some internal refactor of the driver?

Runtime tweaks.

What does this entail?

Otherwise, this is +1, lets for sure break this up and spread the load.

[carllerche]

@LucioFranco Removing Mio from the public API isn't really based on Mio not being 1.0 but more that it exposes too much implentation detail IMO.

"Runtime tweaks" has a linked issue w/ details.

[hawkw]

re:

• Tweak (or temporarily remove) DelayQueue (issue TBD).

Should we just put DelayQueue in util? IIRC, it doesn't depend on anything private that it needs to be in tokio for (though I'd have to double check).