Release Feature Priorities
casey opened this issue · 0 comments
There are many features that release manifests can support, and I'm not totally sure of what order they should be implemented in. The following list is roughly in the order I expect to implement manifest/release related features.
-
#321 – Manifest format: Settled on bencode for the initial implemenation, so this can be closed.
-
#363 – Initial manifest support tracking issue: A pre-requisite to everything else.
-
#324 – Integrity checking: Very easy, probably useful.
-
#452 – Release readme generation: Just a basic readme with facts about the release. Very easy and immediately useful. Once done, later features can be added, like improved styling, etc.
-
#451 – Release information: Can be initially exposed in an auto-generated text file, making it immediately useful in conventional releases.
-
#447 – File MIME Types: Required for serving release content well. Supports lots of other features that requiring figuring out what to do with releases.
-
#448 – Serve contents of a release to a browser: Immediately useful, static server should be very easy.
-
#177 – Structured release type: Probably the feature I believe will have the largest impact. However, lots of work, other things to do first.
-
#323 – Timestamping: A very interesting features. Of dubious usefulness, but could be interesting nonetheless.
-
#449 – Release updates: Only useful with ecosystem buy in, or much further work.
-
#325 – Release signing and verification: Only useful with PKI available, which is out of scope for the project at the moment.