Removing Tock 1.0 crates (timing?)

[jrvanwhy]

Currently, the repository contains both Tock 1.0 crates (libtock and its dependencies) and Tock 2.0 crates (libtock2 and its dependencies). The Tock 2.0 crates are not finished yet (tracked in #322), so it's not clear whether we should delete the Tock 1.0 crates now or later.

The obvious benefit of leaving the Tock 1.0 crates around is it makes it easier for users to continue to use them while they wait for the 2.0 crates to be ready. However, there's also a drawback to keeping the Tock 1.0 crates: they are slowing down the CI, which currently takes about 17 minutes.

Should we keep the crates until the 2.0 crates are ready, or can I go ahead and remove them? Alternatively, as a halfway measure, I can remove them from CI but keep them around in the repository (they shouldn't break if no-one touches them).

I'm personally in favor of removing them sooner rather than later.

[alistair23]

I don't think a 17 minute CI is a reason to remove anything, that is pretty quick.

I think it makes sense to keep the 1.0 crates around until the 2.0 is ready. With efforts like #325 it's worth keeping around

[hudson-ayers]

For the record, I don't think I am going to put in the effort to polish / finish #325 . I don't think it is worthwhile to merge in its current state because most drivers have not been ported, and merging it also risks some out-of-tree user coming to depend on that 2.0 API which we do not plan to maintain in the future. I shared it as a PR in case anyone was interested, but it is at the point where it is temporarily usable for my downstream uses, and I am inclined to focus future effort on Johnathan's 2.0 work.

[alistair23]

With #325 closed and #322 progressing it might be worth re-visiting this

[jrvanwhy]

With #325 closed and #322 progressing it might be worth re-visiting this

I want to update the toolchain to nightly-2022-01-20, or something close to it, in preparation to migrating to stable Rust. Doing so results in a lot of compilation errors because libtock_core still uses llvm_asm!.

I'm inclined to remove libtock_core and everything that depends on it (which is almost all of the Tock 1.0 crates), rather than updating it to use asm!.

[jrvanwhy]

Before we delete the crates, I think we should tag the repository version from before their removal. In fact, I think we should tag a version from before #365 is merged. That way, users who want access to the Tock 1.0 libtock-rs crates can grab the tagged version.

I propose creating the following GitHub release on this repository, please let me know what you think:

Tag

last-tock-1

Title

Tock 1 crate archive

Description

This is a snapshot of the source tree from shortly before the Tock 1 crates were removed.

This is a pre-release

Yes

[hudson-ayers]

That sounds like a good plan to me

[alistair23]

I'm all on board with tagging, I have never had much traction in the past (see #193 and #192).

I think we should tag a 1.6 release, that way it's clear that libtock-rs 1.6 works with Tock 1.6. Then in the future we can tag releases timed up with Tock

[jrvanwhy]

I think we should tag a 1.6 release, that way it's clear that libtock-rs 1.6 works with Tock 1.6. Then in the future we can tag releases timed up with Tock

I'm not sure that libtock-rs releases should be named that way.

cargo is pretty tied to semantic versioning. Under semantic versioning, if we version the libtock-rs crates to match the Tock kernel, then we can't make breaking changes to libtock-rs' APIs without a major Tock revision. I don't think we want that limitation. Therefore we need some other versioning methodology, and I don't want to delay this issue on that discussion.

In the future, when we decide on a versioning scheme for libtock-rs, I think we should be able to go back and retroactively rename the release.

[alistair23]

We can just do another decimal place for changes to libtock-rs.

So for example, Tock 1.6 is released with libtock-rs 1.6 as well. Then libtock-rs fixes a bug and releases 1.6.1. Then Tock fixes a bug and releases 1.6.1. We only tie in the first two numbers, as Tock won't break API inside a major release

I just think that last-tock-1 is a confusing name, and we are stuck with it forever. While v1.6 or 1.6 or release-1.6 is pretty clear.

Either way, I don't care that much. I still think tagging and removing the old stuff is fine

[jrvanwhy]

So for example, Tock 1.6 is released with libtock-rs 1.6 as well. Then libtock-rs fixes a bug and releases 1.6.1. Then Tock fixes a bug and releases 1.6.1. We only tie in the first two numbers, as Tock won't break API inside a major release

The problem isn't bugfixes, it's that libtock-rs will be making breaking changes, while Tock will not be.

[jrvanwhy]

I just think that last-tock-1 is a confusing name, and we are stuck with it forever. While v1.6 or 1.6 or release-1.6 is pretty clear.

I don't think we're stuck with it forever. If we decide to rename it, we can create a new release with the same commit ID but a different name and description.

[jrvanwhy]

Release created: https://github.com/tock/libtock-rs/releases/tag/last-tock-1

I'll start sending PRs to clean up the Tock 1 crates soon.

[jrvanwhy]

#372 removed the Tock 1.0 crates.