A Bundle can have multiple revisions. A call to Bundle.update(…) creates a new revision. There is only ever one current revision (the latest update) associated with a Bundle. Stale revisions continue to exist in the runtime until an explicit refresh of the transitive dependency graph.

Approach #1 - bundle revisions are represented as individual deployments

Each bundle update deploys the revision as a new deployment
The association of revisions to bundle happens in the OSGi layer only
Management sees disconnected deployments with no notion of stale/current or belonging together

Approach #2 - deployment API supports the notion of multiple revisions

deployments, their revisions and respective mapping would be modelled more closely on OSGi requirements
some deployment types might not support revisions