You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From v1.0.0, wws relies on external repositories to fetch the available language runtimes. By default, this project will host the initial metadata:
Index
Polyfills
Wrappers
We will host it as a static assets, while relying on GitHub releases for the different artifacts. Initially, we will generate the index manually based on the WebAssembly Language Runtimes project. We will automate this process in the future by adding several automations in both Language Runtimes and Wasm Workers Server projects.
For the URLs, we plan to segment it by version even it's included in the index spec. This will allow in the future to add redirections and any required change to maintain a better backward compatibility in case we need to change it. So, the final URL will be:
wws will use this metadata unless the user specify a different repository. The name of this repo will be wasmlabs.
Versioning
In the repository metadata we have to version both runtimes and also other files such as polyfills and wrappers. These files have two different, but related versions. In general, a polyfill will work for the major version of a language runtime. However, we may add new features that requires to update these polyfills.
Since the runtime metadata is stored locally in the .wws.toml file, updating a related file (polyfill or wrapper) and the index.toml entries will break developer environments that have references to the previous file version. For this reason, we musn't change polyfills and wrappers after releasing them.
If we need to do so, we will:
Create the new files under a different revision (for example, /repository/v1/files/ruby/3-1/poly.rb)
Create a new release pointing to the new files
Mark the previous one as yanked
This will ensure new installation gets the latest version and existing ones work properly. We will add a warning message asking the users to update to the latest version if this happens.
The text was updated successfully, but these errors were encountered:
@vmware-labs/wasm-languages-maintainers I added a new section called Versioning explaining how runtimes and relates files versions are tight but are independent. Please, left here or in the PR any comment or suggestion around this topic 😄
From v1.0.0,
wws
relies on external repositories to fetch the available language runtimes. By default, this project will host the initial metadata:We will host it as a static assets, while relying on GitHub releases for the different artifacts. Initially, we will generate the index manually based on the WebAssembly Language Runtimes project. We will automate this process in the future by adding several automations in both Language Runtimes and Wasm Workers Server projects.
For the URLs, we plan to segment it by version even it's included in the index spec. This will allow in the future to add redirections and any required change to maintain a better backward compatibility in case we need to change it. So, the final URL will be:
wws
will use this metadata unless the user specify a different repository. The name of this repo will bewasmlabs
.Versioning
In the repository metadata we have to version both runtimes and also other files such as polyfills and wrappers. These files have two different, but related versions. In general, a polyfill will work for the major version of a language runtime. However, we may add new features that requires to update these polyfills.
Since the runtime metadata is stored locally in the
.wws.toml
file, updating a related file (polyfill or wrapper) and theindex.toml
entries will break developer environments that have references to the previous file version. For this reason, we musn't change polyfills and wrappers after releasing them.If we need to do so, we will:
/repository/v1/files/ruby/3-1/poly.rb
)This will ensure new installation gets the latest version and existing ones work properly. We will add a warning message asking the users to update to the latest version if this happens.
The text was updated successfully, but these errors were encountered: