How to re-certify components with new capabilities

[artursouza]

Today, a component can be marked as stable after going through conformance and certification tests. On the other hand, there is no clarify on how to proceed when a new capability is added. Should there be a higher bar for adding new features to stable components or should the component have a new version once a new capability is added?

Example: one state store might be certified as stable before it has support to transactions, later on, the transaction capability is added but it might not be as stable as the current code. Should this be a new component version?

[skyao]

I think this is due to the standard of stable:

should it be versioned like v1 / v2 / v3?

Then we can say that the component is "stable for state v1". When we add some new features in state and we should call it state v2, then current component is still "stable for state v1" and not stable for state v2.

[shubham1172]

+1 for higher bar for adding new features. Features to be only added if they're really important and must be backed up by appropriate certification and conformance tests.

Upgrading a major version for small feature additions sounds counterintuitive in terms of versioning. Revamping a whole component, moving to a new library (for e.g., with Cosmos), scenarios like these maybe more fitting for version upgrade.

[shubham1172]

Then we can say that the component is "stable for state v1". When we add some new features in state and we should call it state v2, then current component is still "stable for state v1" and not stable for state v2.

Do we do this today for general version updates across components? If not, we should totally do it.

[akhilac1]

+1 on making the version intuitive to reflect the stability and feature set. Proper versioning backed by thorough testing will save significant effort in adoption of these components.

+1 on @shubham1172 & @skyao comments on major and minor version update.

It would give users confidence to move to the next version of the component. It would also help the component owners to maintain the quality bar when adding new capabilities.

One additional call-out - while minor versions should always be backward compatible - major version might also be an indicator for the break in backward compatibility. In such a scenario, there is additional responsibility for the component owners to ensure smooth upgrade. Including this check as part of certification would save effort during upgrade.

[yaron2]

Features to be only added if they're really important

Really important according to who? This is, as you can tell by my question, highly subjective. In the realm of criteria it's imperative to be able to make decisions that rely on data that is as objective as possible. So making a decision for certification based on importance, even when coming from maintainers, seems off here.

I think that new features added to stable components must be backed by the same tests as required by all other features of that component. In other words, new features are no different than old features as the existing criteria does not give any special significance to "old" or "new". Only to whether or not they have the required set of tests.

Cases where it's advisable to iterate on a v2 of a component are when breaking changes are introduced, or if the feature is known to be changed ahead of time, during which an Alpha status is appropriate to allow for uninterrupted modifications going forward.

[shubham1172]

In the realm of criteria it's imperative to be able to make decisions that rely on data that is as objective as possible.

[tanvigour]

I agree we should be backing each added feature to stable components with appropriate certification /conformance tests. For versioning, the scope and impact of the added feature should decide whether it should be major or minor version and based on whether the component is still stable or not with that added feature will help users decide on upgrades.

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[dapr-bot]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

[DeepanshuA]

Just a thought: Can we leverage Metadata / Capabilities API enlisting status of a component for a capability. So, in addition, we can have status field telling status (Alpha / Beta / Stable) for a feature for a component.

[berndverst]

@dapr/maintainers-components-contrib and @dapr/approvers-components-contrib need to ensure that any PR impacting a stable components enables applicable conformance tests, and also adds certification tests that cover the new component metadata option.

As long as as this is done diligently I do not think it is necessary to recertify any component.

I would like to propose that no PRs for stable components are accepted unless certification tests are also updated!

I agree with @yaron2 that versioning should only be used for breaking changes.

[ParrySMS]

new capability with new version is a good idea