You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a package imports a package or another module, or if an implementation package implements an API package, then do we constrain what version can be used to override the version in a package?
E.g., an implementation "implement" an IETF BGP package that says that it uses BGP module @ 2.1.0, but the implementation package "overrides" the BGP module to 2.0.0?
E.g., do we say that the version MUST/SHOULD be the same or later?
If we differentiate between API packages and implementation packages then do the same rules apply in all cases?
The text was updated successfully, but these errors were encountered:
In the discussion today, their seemed to be consensus that down rev's should not be allowed.
There seemed to be support for allowing at least minor version uprevs of modules/packages, but it is unclear if there is consensus as to whether major version up revs of modules/packages should be allowed.
In spirit, I think that there was agreement that it isn't appropriate to replace part of an API with something significantly different, but the issue is that we are using Semver and that can flag major version changes even for small bugfixes.
When a package imports a package or another module, or if an implementation package implements an API package, then do we constrain what version can be used to override the version in a package?
E.g., an implementation "implement" an IETF BGP package that says that it uses BGP module @ 2.1.0, but the implementation package "overrides" the BGP module to 2.0.0?
E.g., do we say that the version MUST/SHOULD be the same or later?
If we differentiate between API packages and implementation packages then do the same rules apply in all cases?
The text was updated successfully, but these errors were encountered: