Immutable packages / Version history #8

Metadata for a package version can currently be replaced after changes to the repository.

Problem

Since Composer packages are mutable configurations stored per versions, developers can publish new development versions under the same name. However, this is also true for tagged versions.

When fetching a package there is currently no way of knowing what you’re going to receive or if it’s the same as the day before. This is inherit to Composer which simply resolves package metadata directly from a VCS repository. This makes Composer very versatile as you can fetch the package metadata from different sources, but comes at the price of increased attack vectors from the source.

• Loss of historical metadata makes debugging difficult
• No audit trail for metadata changes
• Consumers can't verify what metadata looked like at a specific point in time
• Compliance and reproducibility concerns for production deployments

Tasks

• Store order of package version links (see Add version link indices #10)
• Store all revisions of package versions (see Refactor package metadata #7)
• Add version history UI (see Add revision history UI #11)
• Add configuration options for retaining old revisions for tagged releases and development releases (see Revision configuration #12)
• Add option to pin the current metadata of a package version (see Allow pinning of package version revisions #13)