Explain futureproofing store files
This commit is contained in:
parent
97816e7d2d
commit
dbbda9bf5d
1 changed files with 20 additions and 0 deletions
|
@ -126,6 +126,26 @@ sub-folders like this:
|
|||
/module/some/sub/folder/example~0.1
|
||||
```
|
||||
|
||||
A given file MUST only exist once with the same path.
|
||||
For example, it is invalid if these files exist at the same time:
|
||||
|
||||
* /foo/bar~0.2
|
||||
* /foo/bar~1.3
|
||||
|
||||
To future-proof the System it is thus necessary to create a disambiguation at
|
||||
the store level. Thus if a library wants to retrieve a file from the Store
|
||||
it MUST at least accept files from it's current advertised version. It MAY
|
||||
accept older files and it MAY transform them and resubmit them in the newer
|
||||
version.
|
||||
|
||||
For this there will be an enum returned for each given Entry. It will have these
|
||||
members:
|
||||
|
||||
- `Compatible`, for version matches
|
||||
- `PossiblyIncompatible`, if the current version is at least a major number
|
||||
further
|
||||
- `Incompatible`, if the file is a at least a major number further
|
||||
|
||||
## Store path links {#sec:thestore:links}
|
||||
|
||||
Linking entries MUST BE version independent.
|
||||
|
|
Loading…
Reference in a new issue