Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preliminary Status #59

Open
BalazsLengyel opened this issue Nov 27, 2018 · 5 comments
Open

Preliminary Status #59

BalazsLengyel opened this issue Nov 27, 2018 · 5 comments

Comments

@BalazsLengyel
Copy link

@BalazsLengyel BalazsLengyel commented Nov 27, 2018

Sometimes we deliver features to customers before they are stable, to give them a working preview of functionality. For this we use the following extension statement

extension preliminary  {
    description
        "The schema node is part of an early design effort. 
     Preliminary nodes SHOULD be, but MAY NOT be fully functional.
         Preliminary nodes MAY be changed or removed in the future 
     ignoring backward compatibility rules. 
        
        The statement MUST only be a substatement of a  
        status statement which has the argument  'current'.
        Zero or One preliminary statement is allowed per parent 
        statement.     
        NO substatements are allowed.";          
}

This violates RFC7950, but there is a real customer need for it.
I would like to see it in YANG next. Ideally we would just allow a new "preliminary"value beside current/deprecated/obsolete for status.

@mbj4668

This comment has been minimized.

Copy link

@mbj4668 mbj4668 commented Nov 27, 2018

I have been thinking about a "status experimental;" which I think would solve the same problem. For upgrade rules, it would be ok to change such a node in any way you like.

@llhotka

This comment has been minimized.

Copy link

@llhotka llhotka commented Nov 27, 2018

In fact, IANA registries often use, apart from OBSOLETE, the EXPERIMENTAL status of their entries. So it would indeed make sense to have status experimental;

@abierman

This comment has been minimized.

Copy link

@abierman abierman commented Jan 16, 2019

Agree with the problem.
Agree with Martin that status-stmt or maybe new module-status-tmt is better
The SEMVER solutions attempt to solve this problem
but only for the first release

@rgwilton

This comment has been minimized.

Copy link

@rgwilton rgwilton commented Jan 16, 2019

Having status "experimental" may be useful. Giving more useful information to a client doesn't seem to be a bad thing.

However, I'm far less convinced that this should then bypass the semver rules. If a client is using an experimental leaf, and the definition changes, then it will still break the client.

Hence, I still think that ultimately to solve the YANG versioning issue, it is necessary to compare the old and new schemas, filter those to the subset of the schema that is being used, and then check to see what has been changed, and what the impact of those changes are.

@llhotka

This comment has been minimized.

Copy link

@llhotka llhotka commented Feb 27, 2019

FWIW, IANA registries also use experimental status. It is described in RFC 8126, sec. 4.2.

@kwatsen kwatsen added this to Definitely Dos (MUST Solve) in YANG Next Mar 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
YANG Next
Definitely Dos (MUST Solve)
6 participants
You can’t perform that action at this time.