Solving Versioning problem with named features

[venkatramanm]

Named features in protocols are bundled into a new version .

Nps could choose to implement some of these features and not all. Having a catalogue of, features implemented by the np at the registry, would make it easy to query for supported features and queried/transacted accordingly.

So version upgrades etc are not required. Only features implemented list in registry is sufficient.

Also dependent features can be consolidated as a group feature with a name.

[venkatramanm]

@ravi-prakash-v

[venkatramanm]

Possible to version features with backwards compatibility or create new feature name if drastically different.

[nitinmish]

Version upgrade and use case implementation need to be looked at differently. Version upgrade will possibly include either breaking changes that will require development effort in processing assimilating information by BAP/BPP, or change user journeys on interfaces. For example, change in serviceability structures between beckn 0.9.3 and 1.1.0 are completely different with introduction of polygon based serviceability.

Use case enhancements fundamentally will only require enhancements of enumerated lists, and possibly a flow diagram for implementation without changing underlying construct of protocol. In this case, the ecosystem participants can propose additions to enumerated lists and proposing flow diagrams of journeys on GitHub. Financial sector specs have adopted this approach and is available in GitHub repository for examples.

Version control shall need to be promulgated through core version of context, however, specific implementation will be suggestive examples in json released under specific domains. This will keep underlying principles of beckn intact enhancing the ability of participants to implement specific use cases.

@ravi-prakash-v @pramodkvarma @BLR-0118 @92shreyansh

[venkatramanm]

Good points @nitinmish , I was thinking more like versioning the serviceability construct instead of the entire protocol. But yes, we can go with versioning the entire protocol for now. But wanted to put on the table an alternate view that may require more granular things versioned instead of a mega version release. That way the upgrades could be possibly better managed since features would be small features.