Dear Ozone community users, The new feature "Support S3 compatible object versioning"( https://issues.apache.org/jira/browse/HDDS-15728) is designed and under development now.
Historically, Ozone supports this boolean "isVersionEnabled" field in BucketArgs and BucketInfo. If a user calls OM rpc to create a bucket, he/she can set this "isVersionEnabled" to true for the newly created bucket. But since bucket versioning is never fully supported in Ozone(except that when "isVersionEnabled" is true, overwrite an existing object will create a new object which have both the new blocks and old blocks merged together), and its true/false state is also not compatible with S3's noEnabled/enabled/suspended three state behavior, and S3 doesn't allow user to enable versioning in the same time when calling the create bucket API, we declared not supporting object versioning later. Now this time, we want to support the object versioning feature compatible with S3 behavior, with bucket has three states, unversioned/version-enabled/version-suspended, and once versioning is enabled, it can be suspended, but cannot go back to unversioned state. We would like to deprecate this "isVersionEnabled" field, and introduce a new "versionStatus" field. Now the question is should we, and to what extent, support the backward compatibility of "isVersionEnabled" field behavior, and does it need to interpret/migrate those might existing bucket data which has field "isVersionEnabled" "true". We would like to know if there is any community user, who is using this existing "isVersionEnabled" and set it to "true". If yes, we would like to know your use cases and what your expectation is for this backward compatible behavior. If no community user ever uses the "isVersionEnabled" and really depends on this field, then we will consider a simple solution, deprecate the "isVersionEnabled" field directly, without any backward compatible behavior support for it. If you are such a user, please let us know your thoughts. Thanks! Sammi Chen
