Task #3374

Support dedicated package versions per context

Added by Robert Lemke about 6 years ago. Updated over 2 years ago.

Status:Rejected Start date:2009-05-19
Priority:Could have Due date:
Assigned To:Karsten Dambekalns % Done:

0%

Category:Package
Target version:-
Sprint: Has patch:No
PHP Version: Complexity:

Description

It should be possible to run different versions of a package depending on the application context. This would allow anyone to test new versions in dev context before staging it to production.

As already discussed, the directory structure should be:

/myhome/Packages/Local/Blog/Development/
/myhome/Packages/Local/Blog/Production/

etc.

It should still be possible to have only one version for all contexts:

/myhome/Packages/Local/Blog/

If there are context specific versions or not can be detected by checking for the existence of the Meta/Package.xml

History

#1 Updated by Robert Lemke about 6 years ago

  • Priority changed from Must have to Could have
  • Target version changed from 283 to 1.0 alpha 2

#2 Updated by Robert Lemke about 6 years ago

  • Target version changed from 1.0 alpha 2 to 283

#3 Updated by Robert Lemke about 6 years ago

  • Target version deleted (283)

#4 Updated by Karsten Dambekalns over 5 years ago

  • Assigned To set to Christopher Hlubek

#5 Updated by Christopher Hlubek over 5 years ago

  • Status changed from New to Accepted

I think the latest consensus was to allow multiple package versions inside each package directory and specify the activated version in the specific (per context) PackageStates.yml, e.g.:

mypath/Packages/Application/Blog/0.2.2/
mypath/Packages/Application/Blog/0.2.3/

and

mypath/Configuration/PackageStates.yml

Blog: 
  state: active
  version: 0.2.2

An explicit version number would allow for a seamless upgrade of packages, since the old package will run as is until the new package is fully installed and activated in PackageStates.yml.

#6 Updated by Karsten Dambekalns over 2 years ago

  • Status changed from Accepted to Rejected
  • Assigned To changed from Christopher Hlubek to Karsten Dambekalns
  • Has patch set to No

This would clash with the way composer manages packages. And in the last years, noone really needed it, or it would have been implemented. ;)

Also available in: Atom PDF