Hi Tsz-Wo
Thanks for your reply,
> BucketInfo#StorageTypeProto can be replaced with .
I think compatibility is fine, but if we change an existing protobuf field,
`proto-backwards-compatibility` will report an error unless
`-DallowBreakingChanges=true` is added during compilation.
But how s
> ... because the proto message `BucketInfo#StorageTypeProto` is marked as
`required`. ...
BucketInfo#StorageTypeProto can be replaced with the new enum since "enum
is compatible with int32, uint32, int64, and uint64 in terms of wire
format". The new StorageTypeProto in hdds.proto will be compat
Hi Tsz-Wo, Abhishek Pal
Indeed, proto2 does not support adding `[deprecated = true]` to enums.
Therefore, I intend to use the `restrict-imports-enforcer-rule` plugin to limit
the usage of these enums that are effectively deprecated, by prohibiting their
import.
However, this approach cannot en
> According to https://protobuf.dev/programming-guides/proto2/#enum , we
should add [deprecated=true] to each field instead of removing the old
protos. Please try.
It seems in the current proto2 version we are using deprecated fields are
not being supported in enums.
Also the reserved keyword tha
> Will there be any compatibility issues after moving enum
`StorageTypeProto` from `ScmServerDatanodeHeartbeatProtocol.proto` to
`hdds.proto` and standardize, and change all the places where
`StorageTypeProto` is used in the existing protobuf to
`hdds.proto#StorageTypeProto`?
There are different l
Dear Ozone Devs,
I am currently developing some features related to StoragePolicy and have
encountered an issue for which I am seeking a solution.
## What I want to do
- Move the enum `StorageTypeProto` from
`ScmServerDatanodeHeartbeatProtocol.proto` to `hdds.proto`.
- Most of the pr
