Skip to content

Immutable packages / Version history #8

@codedmonkey

Description

@codedmonkey

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 all revisions of package versions (see Refactor package metadata #7)
  • Add version history UI
  • Add configuration options for retaining old revisions for tagged releases and development releases
  • Add option to pin the current metadata of a package version

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions