Forum OpenACS Improvement Proposals (TIPs): Tip #20 (Approved): Update package dependencies on major release

Request notifications

~ Abstract
This TIP proposes that a major releases require an update to the APM package dependencies in the .info files to the corresponding APM versions in the emerging major release.

~ Rationale
A major release typically involves significant changes to the kernel and a corresponding update to various packages, such as the ii8n
initiative for the 5.0 release.

- End-users get a consistent system.
- OpenACS developers have to respond to fewer bugs based on version incompatibilities.
- Upgrade scripts are provided so little impact on end-user and sysadmin.

I'm not totally sure I understand this.

Are you saying that we should bump up the dependency information in the .info file for all the packages that have things like noquote, etc..

This makes sense, because they really do depend on the new noquote, internationalization, etc..

So you're saying we should just require that they be done correctly to be in the release?

Agreed.

One note I would like to make here is that right now there is no easy way to say that a package requires a certain release number of OpenACS core (you would have to enumerate all the core packages). I guess in practice though you would never upgrade one core package without upgrading all of them.

Sorry that wasn't clear.

Proposal is that ALL packages get bumped to require latest version of any package they require.

Am also wondering whether there should be explicit kernel dependencies.

Looks like Peter beat me to the punch on the core/kernel idea :)
I guess I'll agree just to make sure everyone realizes this should be so, but really any package that doesn't list its dependencies properly  is broken.  These are bugs, so this is sorta a TIP saying "we should fix bugs" :)

I thought I picked them up for 4.6.3 ... this should be on our  release checklist.

Don,

Hmmm, I never thought about it. So, all packages, no matter if nothing is changed, should increase their version number and require the latest version of whatver packages it requires?

This is most important if packages are distributed seperately from OpenACS. I suppose it makes sense to just coordinate all the "core" package versions because you can use them apart.

As an FYI - I proposed the TIP because I was fixing a bug in forums which required incrementing forums to 1.0d1. While doing so, I saw that the requirement was for notifications 0.1, but the current version of notifications is 4.62 (now 4.64, Lars made another change).

So my only suggestion is - at the time of release - freeze everything - increment ALL dependencies of ALL modules to require latest (5.0) versions.

A little drift is OK, but I think a major release is a good opportunity to get all the packages up to the same watermark for the reasons stated earlier (encourage people to move forward, fewer version incompatibility bugs, etc).