public icon indicating copy to clipboard operation
public copied to clipboard
verified publisher icon openconfig

Add Draft OpenConfig Release Versioning Proposal

Open wenovus opened this issue 3 years ago • 1 comments

wenovus avatar Sep 30 '22 23:09 wenovus

Compatibility Report for commit 4475a6a982ab29c2ca031874e9da7558e0f0e058: ⛔ yanglint@SO 1.10.17

OpenConfigBot avatar Sep 30 '22 23:09 OpenConfigBot

If we have the following history of OpenConfig versions like this: v3.1.0 -> v3.2.0 -> v3.3.0 -> v4.0.0 would there ever be a bug fix, enhancement, or other change made back in, for example, version v3.2.0. (i.e. to create this history) ?

v3.1.0 -> v3.2.0 -> v3.3.0 -> v4.0.0
             \
             v?

Or are new OpenConfig versions always "added to the head" ? i.e. The change would have to be made based off v4.0.0 like this ? v3.1.0 -> v3.2.0 -> v3.3.0 -> v4.0.0 -> v4.1.0

jsterne avatar Oct 24 '22 16:10 jsterne

There was also some discussion in the previous community call about trying to limit non-backwards-compatible (NBC) changes to an annual major update.

jsterne avatar Oct 24 '22 16:10 jsterne

If we have the following history of OpenConfig versions like this: v3.1.0 -> v3.2.0 -> v3.3.0 -> v4.0.0 would there ever be a bug fix, enhancement, or other change made back in, for example, version v3.2.0. (i.e. to create this history) ?

I don't think we're geared as a community to be able to support new patch releases of historical versions. This could change, especially if some circumstance arises that required it, but it does not seem likely to me right now.

Or are new OpenConfig versions always "added to the head" ? i.e. The change would have to be made based off v4.0.0 like this ? v3.1.0 -> v3.2.0 -> v3.3.0 -> v4.0.0 -> v4.1.0

This is the approach we currently follow.

chrisy avatar Oct 24 '22 17:10 chrisy

@wenovus Can you suggest an update based on feedback above?

dplore avatar Nov 14 '22 22:11 dplore

@wenovus Can you suggest an update based on feedback above?

Added a paragraph under point 1 with the approach Chris mentioned.

wenovus avatar Nov 15 '22 00:11 wenovus

Something to consider: using the term "non-backwards-compatible" instead of "backwards-incompatible". Visually its easier to quickly spot the difference (the "in" after dash is a bit more hidden).

jsterne avatar Nov 15 '22 21:11 jsterne

Something to consider: using the term "non-backwards-compatible" instead of "backwards-incompatible". Visually its easier to quickly spot the difference (the "in" after dash is a bit more hidden).

Done. Changed to "non-backward compatible"

wenovus avatar Nov 15 '22 22:11 wenovus

This is a last call for comments on this pull request. This pull request is now scheduled to merge on Nov 30, 2022.

dplore avatar Nov 17 '22 03:11 dplore