Task #3374
Support dedicated package versions per context
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. ;)