docs releases #766
docs releases #766
Conversation
|
| Report | Fri, March 8, 2024 at 11:53:51 UTC |
| Project | Stratum v2 (SRI) |
| Branch | 766/merge |
| Testbed | sv1 |
| Benchmark | Latency | Latency Results nanoseconds (ns) | (Δ%) | Latency Upper Boundary nanoseconds (ns) | (%) |
|---|---|---|---|
| client-submit-serialize | ✅ (view plot) | 6915.200 (+0.73%) | 7139.787 (96.85%) |
| client-submit-serialize-deserialize | ✅ (view plot) | 7983.300 (+1.93%) | 8166.262 (97.76%) |
| client-submit-serialize-deserialize-handle/client-submit-serialize-deserialize-handle | ✅ (view plot) | 8556.400 (+1.96%) | 8726.964 (98.05%) |
| client-sv1-authorize-serialize-deserialize-handle/client-sv1-authorize-serialize-deserialize-handle | ✅ (view plot) | 911.750 (+1.10%) | 947.981 (96.18%) |
| client-sv1-authorize-serialize-deserialize/client-sv1-authorize-serialize-deserialize | ✅ (view plot) | 692.870 (-1.40%) | 734.080 (94.39%) |
| client-sv1-authorize-serialize/client-sv1-authorize-serialize | ✅ (view plot) | 249.070 (-0.18%) | 262.745 (94.80%) |
| client-sv1-get-authorize/client-sv1-get-authorize | ✅ (view plot) | 158.710 (-0.11%) | 167.561 (94.72%) |
| client-sv1-get-submit | ✅ (view plot) | 6696.600 (+0.72%) | 6893.379 (97.15%) |
| client-sv1-get-subscribe/client-sv1-get-subscribe | ✅ (view plot) | 302.420 (+6.94%) | 304.301 (99.38%) |
| client-sv1-subscribe-serialize-deserialize-handle/client-sv1-subscribe-serialize-deserialize-handle | ✅ (view plot) | 775.330 (+2.31%) | 788.620 (98.31%) |
| client-sv1-subscribe-serialize-deserialize/client-sv1-subscribe-serialize-deserialize | ✅ (view plot) | 605.450 (-1.64%) | 641.974 (94.31%) |
| client-sv1-subscribe-serialize/client-sv1-subscribe-serialize | ✅ (view plot) | 203.530 (-1.82%) | 219.067 (92.91%) |
Bencher - Continuous Benchmarking
View Public Perf Page
Docs | Repo | Chat | Help
|
| Report | Fri, March 8, 2024 at 11:53:46 UTC |
| Project | Stratum v2 (SRI) |
| Branch | docs-releases |
| Testbed | sv2 |
| Benchmark | Estimated Cycles | Estimated Cycles Results estimated cycles | (Δ%) | Estimated Cycles Upper Boundary estimated cycles | (%) | Instructions | Instructions Results instructions | (Δ%) | Instructions Upper Boundary instructions | (%) | L1 Accesses | L1 Accesses Results accesses | (Δ%) | L1 Accesses Upper Boundary accesses | (%) | L2 Accesses | L2 Accesses Results accesses | (Δ%) | L2 Accesses Upper Boundary accesses | (%) | RAM Accesses | RAM Accesses Results accesses | (Δ%) | RAM Accesses Upper Boundary accesses | (%) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| client_sv2_handle_message_common | ✅ (view plot) | 2026.000 (-0.14%) | 2086.370 (97.11%) | ✅ (view plot) | 469.000 (+0.61%) | 479.581 (97.79%) | ✅ (view plot) | 731.000 (+0.52%) | 748.445 (97.67%) | ✅ (view plot) | 7.000 (+16.67%) | 9.265 (75.55%) | ✅ (view plot) | 36.000 (-0.92%) | 37.691 (95.51%) |
| client_sv2_handle_message_mining | ✅ (view plot) | 8150.000 (+0.39%) | 8161.806 (99.86%) | ✅ (view plot) | 2133.000 (+0.76%) | 2171.790 (98.21%) | ✅ (view plot) | 3155.000 (+0.79%) | 3226.420 (97.79%) | ✅ (view plot) | 40.000 (+2.89%) | 45.938 (87.07%) | ✅ (view plot) | 137.000 (+0.03%) | 139.178 (98.43%) |
| client_sv2_mining_message_submit_standard | ✅ (view plot) | 6266.000 (-0.51%) | 6437.160 (97.34%) | ✅ (view plot) | 1750.000 (+0.12%) | 1760.262 (99.42%) | ✅ (view plot) | 2551.000 (+0.14%) | 2567.776 (99.35%) | ✅ (view plot) | 22.000 (+5.18%) | 25.267 (87.07%) | ✅ (view plot) | 103.000 (-1.12%) | 108.125 (95.26%) |
| client_sv2_mining_message_submit_standard_serialize | ✅ (view plot) | 14611.000 (-0.72%) | 14894.220 (98.10%) | ✅ (view plot) | 4694.000 (+0.04%) | 4704.262 (99.78%) | ✅ (view plot) | 6756.000 (+0.11%) | 6769.177 (99.81%) | ✅ (view plot) | 52.000 (-2.27%) | 59.888 (86.83%) | ✅ (view plot) | 217.000 (-1.40%) | 224.824 (96.52%) |
| client_sv2_mining_message_submit_standard_serialize_deserialize | ✅ (view plot) | 27264.000 (-0.29%) | 27497.259 (99.15%) | ✅ (view plot) | 10537.000 (+0.02%) | 10547.262 (99.90%) | ✅ (view plot) | 15334.000 (+0.03%) | 15349.256 (99.90%) | ✅ (view plot) | 90.000 (+1.98%) | 93.087 (96.68%) | ✅ (view plot) | 328.000 (-0.81%) | 335.140 (97.87%) |
| client_sv2_open_channel | ✅ (view plot) | 4421.000 (-1.21%) | 4584.672 (96.43%) | ✅ (view plot) | 1461.000 (+0.19%) | 1471.581 (99.28%) | ✅ (view plot) | 2156.000 (+0.26%) | 2169.640 (99.37%) | ✅ (view plot) | 12.000 (+2.49%) | 15.452 (77.66%) | ✅ (view plot) | 63.000 (-2.70%) | 67.578 (93.23%) |
| client_sv2_open_channel_serialize | ✅ (view plot) | 14142.000 (-0.25%) | 14325.406 (98.72%) | ✅ (view plot) | 5064.000 (+0.06%) | 5074.581 (99.79%) | ✅ (view plot) | 7317.000 (+0.07%) | 7331.751 (99.80%) | ✅ (view plot) | 42.000 (-0.20%) | 47.486 (88.45%) | ✅ (view plot) | 189.000 (-0.61%) | 194.319 (97.26%) |
| client_sv2_open_channel_serialize_deserialize | ✅ (view plot) | 22440.000 (-0.41%) | 22671.476 (98.98%) | ✅ (view plot) | 7979.000 (+0.04%) | 7989.581 (99.87%) | ✅ (view plot) | 11615.000 (+0.09%) | 11627.583 (99.89%) | ✅ (view plot) | 72.000 (-4.58%) | 81.386 (88.47%) | ✅ (view plot) | 299.000 (-0.82%) | 305.067 (98.01%) |
| client_sv2_setup_connection | ✅ (view plot) | 4723.000 (+0.14%) | 4768.796 (99.04%) | ✅ (view plot) | 1502.000 (+0.19%) | 1512.581 (99.30%) | ✅ (view plot) | 2273.000 (+0.09%) | 2291.927 (99.17%) | ✅ (view plot) | 14.000 (+20.86%) | 15.504 (90.30%) | ✅ (view plot) | 68.000 (-0.31%) | 69.462 (97.90%) |
| client_sv2_setup_connection_serialize | ✅ (view plot) | 16260.000 (+0.44%) | 16316.039 (99.66%) | ✅ (view plot) | 5963.000 (+0.05%) | 5973.581 (99.82%) | ✅ (view plot) | 8650.000 (-0.03%) | 8672.099 (99.75%) | ✅ (view plot) | 52.000 (+11.13%) | 52.720 (98.64%) | ✅ (view plot) | 210.000 (+0.66%) | 212.113 (99.00%) |
| client_sv2_setup_connection_serialize_deserialize | ✅ (view plot) | 35548.000 (+0.35%) | 35583.262 (99.90%) | ✅ (view plot) | 14806.000 (+0.02%) | 14816.581 (99.93%) | ✅ (view plot) | 21743.000 (-0.02%) | 21768.133 (99.88%) | ✅ (view plot) | 101.000 (+6.32%) | 102.382 (98.65%) | ✅ (view plot) | 380.000 (+0.75%) | 381.413 (99.63%) |
Bencher - Continuous Benchmarking
View Public Perf Page
Docs | Repo | Chat | Help
|
| Report | Fri, March 8, 2024 at 11:53:46 UTC |
| Project | Stratum v2 (SRI) |
| Branch | docs-releases |
| Testbed | sv2 |
| Benchmark | Latency | Latency Results nanoseconds (ns) | (Δ%) | Latency Upper Boundary nanoseconds (ns) | (%) |
|---|---|---|---|
| client_sv2_handle_message_common | ✅ (view plot) | 45.175 (+1.81%) | 45.495 (99.30%) |
| client_sv2_handle_message_mining | ✅ (view plot) | 73.715 (+3.56%) | 80.427 (91.65%) |
| client_sv2_mining_message_submit_standard | ✅ (view plot) | 14.649 (-0.05%) | 14.702 (99.64%) |
| client_sv2_mining_message_submit_standard_serialize | ✅ (view plot) | 270.450 (+1.56%) | 282.477 (95.74%) |
| client_sv2_mining_message_submit_standard_serialize_deserialize | ✅ (view plot) | 576.130 (-0.52%) | 597.860 (96.37%) |
| client_sv2_open_channel | ✅ (view plot) | 171.700 (+1.97%) | 185.185 (92.72%) |
| client_sv2_open_channel_serialize | ✅ (view plot) | 279.580 (-2.41%) | 303.804 (92.03%) |
| client_sv2_open_channel_serialize_deserialize | ✅ (view plot) | 368.660 (-1.90%) | 404.811 (91.07%) |
| client_sv2_setup_connection | ✅ (view plot) | 158.570 (-2.52%) | 169.931 (93.31%) |
| client_sv2_setup_connection_serialize | ✅ (view plot) | 480.360 (+1.39%) | 507.297 (94.69%) |
| client_sv2_setup_connection_serialize_deserialize | ✅ (view plot) | 1035.600 (+6.83%) | 1046.030 (99.00%) |
Bencher - Continuous Benchmarking
View Public Perf Page
Docs | Repo | Chat | Help
|
| Report | Fri, March 8, 2024 at 11:53:46 UTC |
| Project | Stratum v2 (SRI) |
| Branch | docs-releases |
| Testbed | sv1 |
| Benchmark | Estimated Cycles | Estimated Cycles Results estimated cycles | (Δ%) | Estimated Cycles Upper Boundary estimated cycles | (%) | Instructions | Instructions Results instructions | (Δ%) | Instructions Upper Boundary instructions | (%) | L1 Accesses | L1 Accesses Results accesses | (Δ%) | L1 Accesses Upper Boundary accesses | (%) | L2 Accesses | L2 Accesses Results accesses | (Δ%) | L2 Accesses Upper Boundary accesses | (%) | RAM Accesses | RAM Accesses Results accesses | (Δ%) | RAM Accesses Upper Boundary accesses | (%) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| get_authorize | ✅ (view plot) | 8474.000 (+0.09%) | 8542.867 (99.19%) | ✅ (view plot) | 3746.000 (-0.23%) | 3781.929 (99.05%) | ✅ (view plot) | 5249.000 (-0.33%) | 5312.384 (98.81%) | ✅ (view plot) | 8.000 (+21.52%) | 8.460 (94.56%) | ✅ (view plot) | 91.000 (+0.55%) | 91.757 (99.18%) |
| get_submit | ✅ (view plot) | 95529.000 (-0.03%) | 95672.451 (99.85%) | ✅ (view plot) | 59439.000 (-0.05%) | 59559.079 (99.80%) | ✅ (view plot) | 85354.000 (-0.07%) | 85563.361 (99.76%) | ✅ (view plot) | 54.000 (+0.93%) | 56.942 (94.83%) | ✅ (view plot) | 283.000 (+0.30%) | 283.524 (99.82%) |
| get_subscribe | ✅ (view plot) | 8033.000 (+0.39%) | 8083.797 (99.37%) | ✅ (view plot) | 2841.000 (-0.02%) | 2851.338 (99.64%) | ✅ (view plot) | 3968.000 (-0.09%) | 3986.050 (99.55%) | ✅ (view plot) | 15.000 (+5.26%) | 16.538 (90.70%) | ✅ (view plot) | 114.000 (+0.77%) | 115.239 (98.93%) |
| serialize_authorize | ✅ (view plot) | 12227.000 (-0.18%) | 12450.744 (98.20%) | ✅ (view plot) | 5317.000 (-0.16%) | 5352.929 (99.33%) | ✅ (view plot) | 7412.000 (-0.22%) | 7472.384 (99.19%) | ✅ (view plot) | 11.000 (+18.39%) | 12.818 (85.82%) | ✅ (view plot) | 136.000 (-0.31%) | 141.031 (96.43%) |
| serialize_deserialize_authorize | ✅ (view plot) | 24506.000 (-0.05%) | 24631.927 (99.49%) | ✅ (view plot) | 9898.000 (-0.19%) | 9972.100 (99.26%) | ✅ (view plot) | 13956.000 (-0.26%) | 14090.796 (99.04%) | ✅ (view plot) | 38.000 (+6.05%) | 40.768 (93.21%) | ✅ (view plot) | 296.000 (+0.14%) | 297.460 (99.51%) |
| serialize_deserialize_handle_authorize | ✅ (view plot) | 30199.000 (+0.01%) | 30275.025 (99.75%) | ✅ (view plot) | 12101.000 (-0.07%) | 12136.929 (99.70%) | ✅ (view plot) | 17119.000 (-0.10%) | 17185.881 (99.61%) | ✅ (view plot) | 61.000 (+1.10%) | 63.870 (95.51%) | ✅ (view plot) | 365.000 (+0.11%) | 367.317 (99.37%) |
| serialize_deserialize_handle_submit | ✅ (view plot) | 126368.000 (-0.04%) | 126534.091 (99.87%) | ✅ (view plot) | 73224.000 (-0.05%) | 73347.663 (99.83%) | ✅ (view plot) | 104948.000 (-0.06%) | 105162.110 (99.80%) | ✅ (view plot) | 119.000 (+1.82%) | 121.506 (97.94%) | ✅ (view plot) | 595.000 (-0.01%) | 597.428 (99.59%) |
| serialize_deserialize_handle_subscribe | ✅ (view plot) | 27519.000 (+0.12%) | 27571.218 (99.81%) | ✅ (view plot) | 9643.000 (-0.01%) | 9653.338 (99.89%) | ✅ (view plot) | 13634.000 (-0.01%) | 13652.302 (99.87%) | ✅ (view plot) | 68.000 (-1.45%) | 73.169 (92.94%) | ✅ (view plot) | 387.000 (+0.29%) | 388.637 (99.58%) |
| serialize_deserialize_submit | ✅ (view plot) | 115007.000 (-0.08%) | 115361.014 (99.69%) | ✅ (view plot) | 68001.000 (-0.10%) | 68248.327 (99.64%) | ✅ (view plot) | 97557.000 (-0.12%) | 97980.731 (99.57%) | ✅ (view plot) | 67.000 (0.00%) | 69.666 (96.17%) | ✅ (view plot) | 489.000 (+0.12%) | 490.293 (99.74%) |
| serialize_deserialize_subscribe | ✅ (view plot) | 22938.000 (+0.11%) | 22984.745 (99.80%) | ✅ (view plot) | 8195.000 (-0.04%) | 8214.008 (99.77%) | ✅ (view plot) | 11538.000 (-0.08%) | 11576.030 (99.67%) | ✅ (view plot) | 40.000 (+3.56%) | 44.061 (90.78%) | ✅ (view plot) | 320.000 (+0.25%) | 320.983 (99.69%) |
| serialize_submit | ✅ (view plot) | 99846.000 (-0.06%) | 100156.987 (99.69%) | ✅ (view plot) | 61483.000 (-0.05%) | 61603.079 (99.81%) | ✅ (view plot) | 88201.000 (-0.06%) | 88403.929 (99.77%) | ✅ (view plot) | 54.000 (-0.61%) | 56.975 (94.78%) | ✅ (view plot) | 325.000 (-0.03%) | 328.521 (98.93%) |
| serialize_subscribe | ✅ (view plot) | 11366.000 (+0.01%) | 11556.119 (98.35%) | ✅ (view plot) | 4188.000 (-0.01%) | 4198.338 (99.75%) | ✅ (view plot) | 5826.000 (-0.05%) | 5841.424 (99.74%) | ✅ (view plot) | 16.000 (+7.26%) | 17.175 (93.16%) | ✅ (view plot) | 156.000 (-0.03%) | 161.280 (96.73%) |
Bencher - Continuous Benchmarking
View Public Perf Page
Docs | Repo | Chat | Help
|
we should also specify when to run the action. I would say every time that we do PR we need to bump the versions of the affected crates and then run the action in order to do a release. Keep in mine that at least for the lib crates if we try to do release without bumping the version the action will fail so is kinda safe. Of course if bump minor or major or patch is up to the dev but we have review for that. |
plebhash
force-pushed
the
docs-releases
branch
from
3182669 to
0427297
Compare
ack 0427297 |
| Due to either github dependencies or a crate failing the build stage during publish not all crates are being published. | ||
| Whenever a `PATCH` is introduced, it is applied to all the latest `MAJOR` releases. | ||
| For example: imagine there's releases `v1.0.0`, `v1.1.0`, and `v2.0.0`. A bug is found, dating back all the way to `v1.0.0`. | ||
| A patch is applied such that the following new tags are introduced: `v1.1.1` and `v2.0.1`. |
There was a problem hiding this comment.
How do we do it? I guess that we should have a branch (or a tag?) for all the last x majior version of each libs.
This seems complicate. Another way could be to create the branch only when needed. We fix a bug for lib1-2.0.0 we find that also lib1-1.1.0 is affected and we want to backport the fix. We create a new branch from whatever was the state of the repo when lib1 have been go from v1 ti v2 and we apply the fix. If we do that only for last majior version, only when we have a bug that affect also the last majior version I do not think that we will end up with 'too many' branches, considering that most library in this repo will do not get a new majior version in many years. If this is a concern we can just say that we support the last majior version and that is not safe to use any version that is not the majior, or we can think about it when we will have more then one majior version (0 wont be maintained cause is unstable). Maybe we can just leave the various possibility here, for now we can say that we support only last majior so we do not make promise and when we will have more majior we will think about it.
There was a problem hiding this comment.
On lines 10 and 12 of my proposal, there is a very important distinction we need to keep in mind:
SRI has a global version, which uses git tags and keeps track of how the codebase evolves across time as a whole.
Every internal SRI crate also follows SemVer 2.0.0, but each crate version is only set on the respective `Cargo.toml`,
(no git tags), and it evolves independently of the global release version.
Let's imagine this scenario, where both crate-A and crate-B are affected by a bug on the following versions:
| Global Release Version | v2.0.0 | v1.1.0 |
|---|---|---|
| crate-A | v1.0.0 | v0.9.0 |
| crate-B | v2.0.0 | v2.0.0 |
Here, Global Release Versions would be indicated as git tags.
Crate versions however, would only be indicated by Cargo.toml and crates.io. Otherwise, we would end up with too many tags.
After we patch the bug, we would have the following:
| Global Release Version | v2.0.1 (new git tag) | v1.1.1 (new git tag) |
|---|---|---|
| crate-A | v1.0.1 (only bump Cargo.toml) |
v0.9.1 (only bump Cargo.toml) |
| crate-B | v2.0.1 (only bump Cargo.toml) |
v2.0.1 (only bump Cargo.toml) |
There was a problem hiding this comment.
Ok make sense. Only thing I wouldn't maintain version 0 and 1. I would just bump majior version of everyting to 2. And start from there 2 reasons here:
- We didn't followed semver so if you assume semver for what we have now you risk to end up with not compatible libraries.
- There several 0 library that now are 1 that at 0 were very very experimental and it do not make sense to to support them
An example of that is the noise crate.
Also is startum v2 so it can make sense to start from 2. Otherwise we should remove the old library from crates.io but I dont' know if is something possible or not.
There was a problem hiding this comment.
I agree with what you're saying @Fi3, the only thing that bugs me is starting with 2.0.0, afaik we didn't really have an official release yet, and in public we always referred to things as MVP and later update. 1.0.0 is really a nice clean milestone, I am worried 2.0.0 may communicate certain level of maturity and stability which I am not sure we have yet.
Otherwise we should remove the old library from crates.io but I don't know if is something possible or not.
Doesn't sound like something impossible, I doubt there can be any consequences to this?
There was a problem hiding this comment.
With regards to 2.0.0, we should keep the SRI vs SV2 distinction in mind.
Sure, SV2 implies v2, but only for the Specifications.
That doesn't necessarily mean that as a Rust codebase, SRI should start at v2.
There was a problem hiding this comment.
With regards to crates.io removal, I found this:
rust-lang/crates.io#1506 (comment)
which is discouraging... it basically means we will not be able to remove the old libraries from crates.io, and we cannot "start from scratch".
I did understand your point on starting on 2.0.0 @Fi3 . It would be a way to put all SRI crates at the same starting point. But I still think starting on 2.0.0 would be bad, for the reasons I explained in my previous comment.
I wonder if we could do the same, but with all crates starting at 1.0.0?
I did a quick search on all workspaces and I didn't see any crate that is above 1.0.0.
There was a problem hiding this comment.
from @Fi3 (over discord):
main issue is noise crate already 1.1.0 and is not semver 1.0.0 is not compatible with 1.1.0 but jakub told me in the call that you can mark a crate on crates.io as not usable so this could be a solution we could mark all crates like this one as not usable and in that case start from 1.1.0 and mark 1.0.0 as not usable
so assuming we will set all crates to v1.0.0 (except noise-sv2), I crated this PR: #785
There was a problem hiding this comment.
Sounds good. All the 0s will become 1.0.0. All the one already to 1 are yanked and we start from the very next minor. And we say that 0 is not supported anymore.
RELEASE.md
Outdated
|
|
||
| ## Versioning Notes | ||
| Every PR needs to increase the version of whatever crate it is touching. Otherwise, we will mess up the dependency chain of whoever is fetching from crates.io |
There was a problem hiding this comment.
I would specify, every PR in main. PRs that add feature in dev are not going to increase the version number since they will be batched every [duration] into main. So lets say that when I do the release I add 5 feature to lib1 I will not increase the minor version of 5 but of 1.
So when we merge dev in main we increase the versions of the touched libs. When we merge a buge fix in main we increase the version of the touched libs. Whenever we merge something in main we run the releases actions
|
We should decide the interval between release and stick with it, 2 weeks? That means that we do not wait for feature to be ready, every 2 weeks we ship what we have on dev. Also I would add something to automatically check the we do not mess with semver (it is very easy to think that something do not change the API but it change it). I found this linter https://crates.io/crates/cargo-semver-checks that we could add to our actions. That ofc do not remove the needs for human reviews is just an helper. |
ack 22e196e |
RELEASE.md
Outdated
|
|
||
| # Versioning | ||
| Every two weeks all the changes to `dev` are merged back into `main` and then tagged with a release number while bumping `MAJOR` and/or `MINOR`. |
There was a problem hiding this comment.
| Every two weeks all the changes to `dev` are merged back into `main` and then tagged with a release number while bumping `MAJOR` and/or `MINOR`. | |
| Every two weeks all the changes to `dev` are merged back into `main` and then tagged with a release number while bumping `MAJOR` and/or `MINOR`. |
After re-reading the PR the only thing I would be very careful is the pace of releases which we say is 2 weeks.
In startup/company structures this works, but my foss experience says we should probably be more conservative here no matter what type of release it is, I think even with 1-4 PR's it's obvious things can take quite a lot of time, especially if mainnet testing or any sort of testing is involved.
I would say we probablt shouldn't put a time-frame here, or we can put a 2-4weeks - until we do trial and error and see what kind of pace works for the structure/team we have here.
Trust me, 2-weeks is very tight in FOSS and can cause of lot of stress. As a reminder we're 8 months behind this release (ok it's major but just to give you a bit more realistic overview). What happens if we have PR's depending on each other and each of them requires testing (situation we had last 4-6 weeks).
FOSS structures are much loose and time-frames should adjust to that imo.
There was a problem hiding this comment.
I'm not opinionated on this, and I do see your point.
Over Discord I think you expressed a slightly different idea. There you're suggesting a 4 week release cycle.
Did you change your mind after writing this comment here (maybe during today's call)?
Either way is fine, just asking so I can change the wording on the PR. Also, feel free to suggest some direct changes to RELEASE.md if you want.
There was a problem hiding this comment.
I would say 4 weeks was a consensus, but I still believe this is very optimistic. But for now we agreed we try with 4 weeks, and then see how it works for the team.
| Due to either github dependencies or a crate failing the build stage during publish not all crates are being published. | ||
| Whenever a `PATCH` is introduced, it is applied to all the latest `MAJOR` releases. | ||
| For example: imagine there's releases `v1.0.0`, `v1.1.0`, and `v2.0.0`. A bug is found, dating back all the way to `v1.0.0`. | ||
| A patch is applied such that the following new tags are introduced: `v1.1.1` and `v2.0.1`. |
There was a problem hiding this comment.
I agree with what you're saying @Fi3, the only thing that bugs me is starting with 2.0.0, afaik we didn't really have an official release yet, and in public we always referred to things as MVP and later update. 1.0.0 is really a nice clean milestone, I am worried 2.0.0 may communicate certain level of maturity and stability which I am not sure we have yet.
Otherwise we should remove the old library from crates.io but I don't know if is something possible or not.
Doesn't sound like something impossible, I doubt there can be any consequences to this?
Co-authored-by: Pavlenex <[email protected]>
|
Gave it another round of review, besides 4 week time-frame for a release, I don't see vulnerability/critical releases and how we handle those? Are those considered a patch, and if so does it mean a critical vulnerability will be patched within whatever time-frame we agreed on (2 or 4 weeks)on or is it instant? I don't mean define vulnerability response processes, but rather when a critical vulnerabilty is found how is it handled in a release cycle. Step by step on vulnerability response can be done in a separate security.md Generally with releases, it sounds odd, but it's storytelling. We want to tell a story, ,motivate the users and community why certain release brings good functionality, improvements or fixes is very important for users, helps build excitement and community around releases and encourage people to try them out and report back if they find issues. With short release cycle, this is really tricky. I've checked how other projects do it, and BDK does it every 4 weeks, and LDK does it every two months. I think for us it'll be trial and error and we may decide to change things as we learn more on what works for us. The biggest advantage of this PR is that it introduces some structure, and more importantly consensus on versioning. Time-frames and other things, can always changde depending on the structure of contributors and community. Just as an example, our first update was 6 months late, and the second one is probably few months behind (hard to say since we keep switching deadlines, but according to the latest deadline we're 20days behind). |
RELEASE.md
Outdated
|
|
||
| # Versioning | ||
| Every 4 weeks all the changes to `dev` are merged back into `main` and then tagged with a release number while bumping `MAJOR` and/or `MINOR`. |
There was a problem hiding this comment.
I agree with all @pavlenex's considerations about the 4 weeks period. I'm very skeptical about it and I don't see a need for it to be that strictly to be honest. Why not defining a time period at all? Or put it larger (2 months)?
Since with this release we finally implemented everything from the specs, I don't expect that many new features in a short-mid time frame. I'm sure we will need to make more patch releases than feature ones btw
There was a problem hiding this comment.
ok this point is generating a lot of confusion so I propose we leave the document like this for now:
- Every 4 weeks all the changes to `dev` are merged back into `main` and then tagged with a release number while bumping `MAJOR` and/or `MINOR`.
+ The SRI team will decide the appropriate time when the changes to `dev` are merged back into `main` and then tagged with a release number while bumping `MAJOR` and/or `MINOR`.we can revisit this point in the future if necessary, but for now, we leave the date for v1.1.0 to be defined.
what do you think @Fi3 ?
There was a problem hiding this comment.
I'm sure we will need to make more patch releases than feature ones btw
I can understand this point, and I wonder if we can do something about it.
While we already have a strategy for dealing with bugs under SemVer 2.0.0, IMO we should keep that for exceptional situations where finding a bug is actually a surprise.
With that in mind, I propose that we start our release cycle with v1.0.0-beta.0 instead of v1.0.0.
As we fix bugs, we increase v1.0.0-beta.1, v1.0.0-beta.2, etc.
When we feel confident, we can finally move to v1.0.0 as a stable release.
(This suggestion is only related to global SRI releases. The internal crate versioning proposed on #785 can continue the same).
There was a problem hiding this comment.
I understand your point about v1.0.0-beta.1, v1.0.0-beta.2 but I am slightly worried on what that communicates to the public, and something as simple as a tag could drive people away from implementing and just keep them in "I'll wait a bit more stage", and I am not sure about you guys, but I am tired of SV2 being in "pending" state. We need to push forward.
1.0.0 communicates that after 3+ years this is ready to be tested and adopted, sure there will be bugs, sure there's a LOT of work to be done to ensure stability, and probably a whole can of worms once different configurations and use-cases start being used, but... this is our opportunity to start fresh and clean, and I feel these tags would kill the momentum of excitement around something as significant as 1.0.0, so I'll really keep things as we already agreed, besides timeframe for releases seems we have a consensus. Timelines can easily be adjusted.
There was a problem hiding this comment.
Yeah now I would try to release it as 1.0.0, without specifying a timeframe for merging dev into main and push a new release. After that, we will see how we can be more specific about timeframes, depending on external feedback and testing!
I think that falls under the definition of bugs and patches. Since we are leaving the timelines open for releases, I guess there's no point in specifying that for patches as well? Anyways, IMO these questions are already answered in these lines: @pavlenex let me know if you feel we should elaborate more on this. |
Refactoring of docs about releases.