-
Notifications
You must be signed in to change notification settings - Fork 249
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
Repository organization #360
Comments
I'm not super fan of date-named versions since date doesn't convey meaning. However if date-named versions are the way to go I'd prefer using a convention such as |
One good thing about What extra meaning might we want to covey with out snapshot releases versions? At least date-based scheme is strictly more meaningful than monotonic integers. |
All these changes would greatly improve the directory structure and scale better than the current organization.
|
It's a bit easier to assess (breaking) changes on |
Date-based versions are useful for communicating the WASI snapshot used by toolchains and libraries without confusing it for the actual version of that toolchain or library. Another closely related problem it solves is the stagnation of snapshots. We have had snapshot 1 out for a year now without committing to a date to release the next one, because we don't have tooling that can handle ephemeral right now. We need to get unstuck from this situation by putting time into the tooling, but to prevent this from happening in the future, a release train schedule will keep everyone honest on only merging changes once the tools actually support them. Its possible for a release train to use monotonic integers, but if the goal of those integers is just to communicate a snapshot in time and not a semantic version it makes more sense to just use a date. According to semver, every change we have made in WASI so far is a major version breaking change, and nearly every change I can think of for the future is one as well. So, using semver is the same as sticking to the current monotonic integer scheme. We have put a lot of thought into describing the differences and compatibility between versions in mechanical ways, but one big problem is that both the WASI interfaces themselves, and the technology used to specify those interfaces (witx, proposals like reference imports, interface types, etc) are both in flux. Therefore, we concluded that the best we should do, until the technology to specify WASI is stable, is provide human-readable changelogs and use doc comments to describe similarities and differences to prior versions. Since we don't yet know what the end state of this process will look like, lets defer figuring out how to describe the semantic differences to a machine (via semver, and other mechanisms) until we're on more stable ground. It will be at least a year, probably 2, before WASI is based on top of a stage 4 interface types proposal. At that point, semantic differences become a lot more meaningful and useful. |
Oh see, you are both talking about compatibility between versions. That issue I think should be considered separately. There has been fair amount of discussion on that issue in past: See #2. |
Following the organization sketched out here: #360 This PR adds several new directories and starts a work-in-progress make-snapshot.sh script for creating snapshots. The `phases` directory is not yet removed; that can happen once we've transitioned everything to the new organization.
If date-based names end up winning, please consider padding the months and days to 2 digits, eg. "2021-01" instead of "2021-1". This ensures that the alphabetic order == chronological order. |
Yes; this is also the ISO-8601 YYYY-MM format. |
Following the organization sketched out here: #360 This PR adds several new directories and starts a work-in-progress make-snapshot.sh script for creating snapshots. The `phases` directory is not yet removed; that can happen once we've transitioned everything to the new organization.
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the main branch in this repository to be the same as that if the WASI repository, and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that.
As part of the move to modularize WASI, I've now reset the main branch in this repository to be the same as that if the WASI repository, and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that.
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
wasi-filesystem, wasi-clocks, wasi-random, wasi-poll, wasi-classic-command, wasi-handle-index, and wasi-io now all have PRs updating them to be WASI forks with patches on top. |
As part of the move to modularize WASI, I've now reset the `main` branch in this repository to be the same as that if the [`WASI` repository], and this is now a PR on top of that. This implements the directory structure described in WebAssembly/WASI#360, with a standard directory, and a wasi-clocks directory under that. [`WASI` repository]: https://github.com/WebAssembly/WASI/
The proposals have now been moved into their own repositories. There is a proposal template for new proposals. The central WASI repository has been reorganized and significantly simplified. |
Currently the main directory organization in the WASI repository looks like this:
phases/
ephemeral/
snapshot/
old/
snapshot_0/
I've recently talked with several folks about how to better organize proposal repos, and we came up with several ideas which seem to fit well together which I'd like to discuss:
snapshot/
pointing at the current snapshot andold/
add old snapshots. We can have a link in a README file pointing to the latest revision if that would help, but being able to refer to a specific snapshot URL would be useful. This was suggested in Consider giving the current snapshot a number #261, and I now think it makes sense to do in combination with the other ideas here.ephemeral/
directory with a proposal template. The way this will work is:proposal-template/
and move it out ofphases/
.standard
directory, which in the main WASI repo here will be empty until some proposal reaches stage 5, but which in the proposal repo forks will contain the most recent version of the proposal.update-testsuite.sh
in the wasm testsuite repo, which copies thestandard/
contents from the proposal repos into a date-basedsnapshots/
subdirectory.So the new structure would be:
phases/
goes awayproposal-template/
at the top level contains a template for new proposalssnapshot/
standard/
This will, at last, be part of a clear path forward for releasing a new snapshot using the proposal repos. Thoughts?
The text was updated successfully, but these errors were encountered: