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
Sub-packages in the package registry are exposed also as modules. When making refactors in the registry this forces us to maintain backwards compatibility, or risk breaking dependent projects, while the package registry is not generally intended to be used as library.
Move internal functionality to internal modules, and clarify what functionality can be used externally. For example it may make sense to keep public the structs that are mapped to JSON API objects. But almost any other functionality should be probably internal.
This change will be breaking for projects using the registry as library, and require to bump to a v2 version.
The text was updated successfully, but these errors were encountered:
Sub-packages in the package registry are exposed also as modules. When making refactors in the registry this forces us to maintain backwards compatibility, or risk breaking dependent projects, while the package registry is not generally intended to be used as library.
Move internal functionality to internal modules, and clarify what functionality can be used externally. For example it may make sense to keep public the structs that are mapped to JSON API objects. But almost any other functionality should be probably internal.
This change will be breaking for projects using the registry as library, and require to bump to a v2 version.
The text was updated successfully, but these errors were encountered: