Consider releasing 0.2.0 as 1.0

[Ekleog]

Just an idea: tokio appears, to me, to already be handled with stability guarantees usually expected from crates that have reached 1.0.

Would it be reasonable to release 0.2.0-alpha.6 as 1.0 when it gets done, so that the breaking semver change needs to be lived only once? 2.0 can be released after anyway if need be, but at least it'd help the ecosystem start to “look venerable”, which might help for public relations from time to time.

To substantiate my point, tokio 0.1 has been alive for ~2 years, which is a quite reasonable time to live for a major release, and is AFAIU thinking of releasing 0.2 mostly to accomodate the now-stable futures, so it's kind of unlikely to see a 0.3 anytime soon as far as I understand.

[carllerche]

It's an idea. I haven't thought through all the options yet. I'm mostly trying to focus on shipping.

I'm hesitant to jump straight to 1.0 as Tokio is going through a massive massive change right now (including all the way down to how it interfaces w/ OS apis), but I think there is a path to 1.0 in the not too distant future.

[DoumanAsh]

I think we need at least stable Stream trait before doing so.

[dekellum]

IMO, the primary advantage of releasing a 1.0.0 is not as some kind of badge of maturity. Maintainers are frequently, as above, uncomfortable with such an endorsement, and the rust ecosystem seems particularly indisposed. Meanwhile:

https://semver.org/#how-do-i-know-when-to-release-100

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

More pragmatically, releasing as 1.MINOR.PATCH means that future new features and minor compatibility concerns like MSRV and dependency bumps can be grouped as (semver compatible) MINOR changes while bug fixes, safe performance improvements, etc. can be releases as PATCH changes. Releasing MAJOR changes as 2.x, etc. is no more onerous then releasing a 0.3. I suspect that having the extra version decimal position available will be even more helpful given the current direction to collapse to fewer crates and in particular the larger, feature-gated, tokio crate. Without it, all changes are either semver breaking (0.3, 0.4, etc.) or semver conventions are bent to make what are really breaking changes in PATCH releases (0.2.1, 0.2.2)

In #1348 (and 0.1.x changes like #1451 and #1604 actually released) it would have been preferable to release a new MINOR with the dependency and MSRV bumps. But with the 0.2 plan in place, no such MINOR digit was available. Putting all of MAJOR.MINOR.PATCH in play, better supports the option of backporting bug fixes and other maintenance while new MAJOR or MINOR branches are developed in parallel.

[carllerche]

You are not wrong... but given the scope of the changes we are about to release, should we release them as 0.2, wait a bit, tweak the API then cut 1.0 or should we go straight to 1.0?

There have been HUGE API changes in the past few months.

[Ekleog]

If, when releasing 0.2, you also say “we'll release 1.0 on 20xx-yy-zz whatever happens,” then that handles my concern, I guess, and it'd maybe sound like a good middle ground?

This way there shouldn't be a need for too many patch-level releases, and the release will explicitly be cut off at a defined point in time. That said, it'd mean that even if there are no API changes 1.0 should be cut on that date -- which somehow makes me think that releasing it immediately might make sense.

Another alternative would be to keep 0.2.0-alpha.* until being pretty sure of the API, maybe a few more months, and then release 1.0 directly -- my fear is churn in the ecosystem twice (even though IMO the ecosystem shouldn't have tokio as a direct dependency but rely on an abstraction layer, it's not what appears to be happening)

[carllerche]

@Ekleog Alphas are too painful for the ecosystem.

I think we can hit 1.0 in 2020 even if there are no API changes :)

[Ekleog]

Well, not having the ecosystem adapt to 0.2 and then have to churn everything again to 1.0 is actually the point of the idea of keeping an alpha for longer :)

[dekellum]

@carllerche writes:

we can hit 1.0 in 2020 even if there are no API changes

Typically the way this has played out: You'll release 0.2 to great success, and once the dust settles, there will be little enthusiasm about bumping the MAJOR version, without API changes, only for the sake of establishing 1.0.0. This repeats for version 0.3, 0.4, etc.

I'm trying to raise your courage to release 1.0.0 sooner. 😊

[carllerche]

If there are no breaking changes that is the best scenario! We can release 1.0 without breaking anything

[carllerche]

Either way. I think we can set a hard date in 2020

[Ekleog]

Releasing 1.0 still forces a major upgrade of all crates that expose elements of tokio in their public API, due to semver handling in cargo. Does it not?

[carllerche]

Tokio 0.2 can have a patch release that depends on tokio 1.0 and re-exports its types.

[Ekleog]

Oh right, the semver hack, had forgotten about it. Setting a 1.0 release date in 2020 works for me, then, thanks! :)

[carllerche]

How does Q3 2020 sound?

[Ekleog]

Sounds great to me, and judging from the reactions on your post most other people agree! Do you think it'd make sense to release this as an announcement alongside the 0.2.0 release? :)

[carllerche]

@Ekleog yeah! Sounds great.