Task #3374

Support dedicated package versions per context

Added by Robert Lemke over 12 years ago. Updated almost 9 years ago.

Status:
Rejected
Priority:
Could have
Category:
Package
Target version:
-
Start date:
2009-05-19
Due date:
% Done:

0%

Estimated time:
Sprint:
PHP Version:
Has patch:
No
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

#1

Updated by Robert Lemke over 12 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 over 12 years ago

  • Target version changed from 1.0 alpha 2 to 283
#3

Updated by Robert Lemke about 12 years ago

  • Target version deleted (283)
#4

Updated by Karsten Dambekalns almost 12 years ago

  • Assignee set to Christopher Hlubek
#5

Updated by Christopher Hlubek almost 12 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 almost 9 years ago

  • Status changed from Accepted to Rejected
  • Assignee 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