Update readme #10
Update readme #10
Conversation
nsarlin-zama
force-pushed
the
update_readme
branch
7 times, most recently
from
9a8888c to
e352d50
Compare
nsarlin-zama
force-pushed
the
update_readme
branch
from
e352d50 to
9964ec9
Compare
| # Usage | ||
| In TFHE-rs main repo, run the following command | ||
| ``` | ||
| make test_backward_compatibility | ||
| ``` | ||
| This will clone this repo and check if all messages are handled correctly. By default, this will use the `v0.1` branch (see below). To use a different branch, use this command instead: | ||
| ``` | ||
| BACKWARD_COMPAT_DATA_BRANCH=my_branch_name make test_backward_compatibility | ||
| ``` |
There was a problem hiding this comment.
could be useful to have in the main repo as well somewhere, I guess we could start a sort of developer guide
There was a problem hiding this comment.
or have a small guide in TFHE-rs that refers to this readme/doc
There was a problem hiding this comment.
I created an issue about adding a contributing guide in tfhe-rs
|
|
||
| However, this does not allow changes to be made to the test metadata scheme itself. In such a case, a new version branch should be created (e.g. `v0.2`), and TFHE-rs should use that branch instead. | ||
|
|
||
| Any commits to `main` should be backported to the latest version branch. |
There was a problem hiding this comment.
Since TFHE-rs uses the branch v0.1 we need to backport commits from main into v0.1, or they won't be used. If we add a breaking change to the metadata format we will have to create a v0.2 branch, and at that point we will have to backport commits into v0.2.
There might be an easier way to do this.
There was a problem hiding this comment.
well as long as main == v0.1 keep v0.1 on the same branch
the day it changes v0.1 stops moving and we put v0.2 at the tip of main, unless we expect to backport on v0.1 but once we switch to 0.2 it's a done deal right ?
Adds instructions in the README