Index: openacs-4/packages/acs-core-docs/www/eng-standards-versioning.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/eng-standards-versioning.html,v diff -u -r1.54.2.3 -r1.54.2.4 --- openacs-4/packages/acs-core-docs/www/eng-standards-versioning.html 27 Jun 2019 18:22:21 -0000 1.54.2.3 +++ openacs-4/packages/acs-core-docs/www/eng-standards-versioning.html 3 Sep 2021 09:14:58 -0000 1.54.2.4 @@ -91,7 +91,7 @@ coding standards; is fully internationalized; available on both supported databases.

  • Level 4: Deprecated. The package was in some earlier version - is use, but was probably replaced by a another package. The + is use, but was probably replaced by another package. The package description should point to a preferred version.

  • Naming Database Upgrade Scripts

    Database upgrade scripts must be named very precisely in order for the Package Manager to run the correct script at the correct time.

    1. Upgrade scripts should be named /packages/myfirstpackage/sql/postgresql/upgrade/upgrade-OLDVERSION-NEWVERSION.sql

    2. If the version you are working on is a later version than the current released version, OLDVERSION should be the current version. The current version is package version in the APM and in /packages/myfirstpackage/myfirstpackage.info. So if forums is at 2.0.1, OLDVERSION should be 2.0.1d1. Note that this means that new version development that includes an upgrade must start at d2, not d1.

    3. If you are working on a pre-release version of a package, use the current package version as OLDVERSION. Increment the package version as appropriate (see above) and use the new version as NEWVERSION. For example, if you are working on 2.0.1d3, make it 2.0.1d4 and use upgrade-2.0.1d3-2.0.1d4.sql.

    4. Database upgrades should be confined to development releases, not alpha or beta releases.