Packages: Difference between revisions
Adamcolton (talk | contribs) No edit summary |
Adamcolton (talk | contribs) No edit summary |
||
| Line 22: | Line 22: | ||
When releasing a patch version, the tests from all previous versions in the minor branch must pass. The package interface cannot change. When releasing a minor version, all tests from all previous versions must pass, and the previous version must be compatible with the current version. This will allow some coercion though. A function that accepted a single value and now accepts a variadic is ok. Something that accepted a concrete type and now accepts an interface is ok. Something that returned an interface and now returns a concrete type that fulfills that interface is ok. | When releasing a patch version, the tests from all previous versions in the minor branch must pass. The package interface cannot change. When releasing a minor version, all tests from all previous versions must pass, and the previous version must be compatible with the current version. This will allow some coercion though. A function that accepted a single value and now accepts a variadic is ok. Something that accepted a concrete type and now accepts an interface is ok. Something that returned an interface and now returns a concrete type that fulfills that interface is ok. | ||
Major packages are really considered to be a separate package. | |||
=== Version Collisions === | |||
This creates an issue. If an application tries to include packages A and B which both include C but A includes C3.2.1 and B include C3.1.2, this is not ok. | |||
I think the best solution is to always use the highest minor version from any package included. | |||
== Security == | == Security == | ||
Revision as of 14:37, 23 September 2019
There are 3 types of packages that change how the environment is treated.
Application
This is package main in Go. An application provides an entry point.
I may also limit access to some resources to the Application. For instance os access. In that case, os will provide a file system object that can be passed into any library or module that needs it, but it means that the application knows what's happening.
Library
A library is intended for re-use.
Only a library can access reflection and unsafe. Though not all libraries must.
Libraries have a very high testing and documentation burden.
Module
A module is intended to scope application logic. While a module may be shared between a few applications, it's not intended for wide, general purpose re-use.
Versioning
Package versioning is separate from source control versioning. A fully qualified version has Domain, Package, Major version, Minor version, Patch version and a file list.
The file list is sorted by name and includes the hash of each file. The packages form a cryptographic linked list (yeah, a blockchain) where each minor and patch version point to the previous. All the data is included in a package hash. Also needs to include a list of packages that it uses, their version and hash.
When releasing a patch version, the tests from all previous versions in the minor branch must pass. The package interface cannot change. When releasing a minor version, all tests from all previous versions must pass, and the previous version must be compatible with the current version. This will allow some coercion though. A function that accepted a single value and now accepts a variadic is ok. Something that accepted a concrete type and now accepts an interface is ok. Something that returned an interface and now returns a concrete type that fulfills that interface is ok.
Major packages are really considered to be a separate package.
Version Collisions
This creates an issue. If an application tries to include packages A and B which both include C but A includes C3.2.1 and B include C3.1.2, this is not ok.
I think the best solution is to always use the highest minor version from any package included.
Security
This is implemented at a package level. Signatures are based on EigenTrust. So a user can place partial trust in a few base organizations and compute aggregate trust in any organization from there.
But trust isn't needed for all packages. Trust level required is computed from the state of the package.
Applications that don't access restricted resources don't require any trust.