Add a specific tag when getting operations #2
Conversation
This would prevent importing breaking changes in the future! Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
|
I will tag this repo |
| @@ -19,6 +19,7 @@ use std::process::{Command, Output}; | |||
|
|
|||
| const PROTO_FOLDER: &str = "target/parsec-operations/protobuf"; | |||
| const PROTO_OUT_DIR: &str = "src/operations_protobuf/generated_ops"; | |||
| const PARSEC_OPERATIONS_VERSION: &str = "0.1.0"; | |||
There was a problem hiding this comment.
[NIT] This could be put in Cargo.toml to keep all dependencies specified in one place, but it might not be worth the effort
There was a problem hiding this comment.
Are you thinking of doing the same than in parsec, ie:
[package.metadata.config]
mbed-crypto-version = "mbedcrypto-1.1.0"
I think that is a good idea!
There was a problem hiding this comment.
That sounds good but it does mean more code in build.rs which might not be justified. Whether it's in Cargo.toml or build.rs doesn't feel like critical to me, but maybe someone seeing the code for the first time would find it easier to understand the dependencies
There was a problem hiding this comment.
To keep things simpler and avoir making build.rs more complicated, I'll keep the tag in build.rs.
| // TODO: using tagging and releases, this could maybe be faster: downloading a .zip release file | ||
| // and decompressing it. | ||
| // TODO: Downloading a release file and decompressing it might be faster here. | ||
| // TODO: Use semantic versioning to get the newest versions. |
There was a problem hiding this comment.
https://crates.io/crates/git2 this should come in handy, both for the semantic versioning check and for the command below.
There was a problem hiding this comment.
If we use the release package instead we might just download it with wget I think. It would be useful if it can list the tags available on a repo so that we can choose the one compatible with our semantic version?
This would prevent importing breaking changes in the future!
Signed-off-by: Hugues de Valon hugues.devalon@arm.com