Forum OpenACS Development: Response to UPGRADE Scripts PLEASE

Collapse
Posted by Vinod Kurup on
Argh! another problem... I mentioned above that not all the files in openacs-4-5 got merged into the CVS HEAD. I thought that it was just .info files and some doc files (which I manually merged). I just noticed that some bugfixes didn't get merged over, as well. Specifically (and ironically), I fixed a bug so that upgrade-checking in the APM worked (PG). This was in 4.5, but didn't get merged into the HEAD. When Jon made the acs-kernel upgrade script, he noticed that apm_package_version__upgrade_p was changed, so he properly dropped the function and recreated the "new" one, which, of course, is the old buggy one. Fortunately, he didn't bump the version yet, so I'm going to fix the problem in CVS, touch up the acs-kernel upgrade scripts, and look to see if any other code didn't get merged properly. Anyone that manually upgraded using Jon's script should drop apm_package_version__upgrade_p and load the version that will be in CVS in a few minutes 😊

Other comments:

  • I think it's better to adjust the .info file via the UI, because there are multiple places to set it (as Yon notes), and if you do it via the UI, the APM automatically upgrades the version on your system to the new version *without* running the upgrade scripts (since you've presumably been developing and testing before you change the .info file). You do need to remember to change the 'provides' as well in the 'Manage Dependencies' section.
  • Should module owners attach a CVS tag to their module when they upgrade the version? This would make it easier to track which changes have occurred between versions, now that module versions will not correlate 1-to-1 to openacs versions. Is it even possible to TAG just one module?
  • There is a doc on version numbering, but it doesn't discuss these issues - https://openacs.org/doc/openacs-4/eng-standards-versioning.html
  • Setting the "provides" is a no-brainer. Setting the "requires" is much more complex. Packages which currently 'require' your package don't necessarily belong to you and may not be in your control - e.g. my proprietary rule-the-world v0.1d package (in stores soon!). This is going to need some good communication between packages (via detailed ChangeLogs?) so a package knows whether they need to bump-up their 'requires'