Forum OpenACS Development: 4.6 release checklist

Posted by Jeff Davis on
I think we should put together a release checklist (for 4.6 and beyond). Here were the things I came up with:
  • Update major/minor versions in DocBook docs.
  • Update readme.txt
  • Regenerate .html docs from DocBook
  • Make sure release notes are up to date
  • Make sure the checkout is clean and the file protections are correct
  • Make sure you can bootstrap on postgresql and oracle
  • Make sure there are not excessive notice/warning messages generated when running a server.
  • Tag CVS
  • create dist files (tarball, etc)
  • add version to SDM
Posted by Don Baccus on
Do you want to work with Janine on this?  We should put together a checklist and save it somewhere for future releases - somewhere other than in the forums.  We have the status sheet for development that Janine's maintaining, we could create s similar checklist style status sheet for the release process itself ...
Posted by Jeff Davis on
I was hoping that there would be a flood of posts which we could pull together into a permanent document.  No flood yet, but I am sure it
will happen soon :)

I will make sure Janine gets a summary for the permanent record.

Posted by Vinod Kurup on
Well, you asked for a flood, so how bout...
  • Making sure all the core packages have upgrade scripts
  • Updating all the core package .info files
  • Once the HTML docs are generated, the docs should be updated to the new version
  • Announcing the new version (bboard, news, etc)
  • Merging 4.6 changes back into the head (actually - not sure when this happens)
BTW, is anyone actively working on upgrade scripts right now? If not, I can try. I did a quick look and the following core packages need 'em:
  • acs-content-repository
  • acs-kernel
  • acs-mail
  • acs-service-contract
The upgrade scripts all seem trivial except the acs-kernel one. acs-kernel changed some columns from varchar(100) to varchar(1000). We could drop the tables and recreate them, but then all the views and rules based on the tables would also have to be recreated. An article on suggests that the only *right* way to change column datatypes is to pg_dump, manually edit the dump file and then pg_reload (which seems like overkill, especially if the user doesn't require the longer field). How should we approach this?
Posted by Jon Griffin on
I noticed that in acs-kernel also and it does cause things to choke.

I would like to know who changed this and why to chastise them publically for breaking the kernel without even a note.

Again, please don't change the kernel without a good reason and posting it on the board for public scrutiny.

Posted by Jeff Davis on
I changed the column widths when I merged the changes from sloanspace and they increased them there because they were too small. I did not write an upgrade for it since it did not look to me like you could write an upgrade for it (and because I am a bad bad man).

It's all there in black and white in the cvs log.

revision 1.15
date: 2002/09/16 21:52:42;  author: jeffd;  state: Exp;  lines: +3 -3
increase field sizes (from sloan)
I think people can upgrade happily from 4.5 to 4.6 (or could if there were more upgrade scripts) without changing these field widths and I am curious why you think it causes things to choke Jon.

In the future I will try to post something to the bboards before I make a change like that.

Posted by Jon Griffin on
I don't think requiring people to read cvs logs is a real way to document changes in the core of an app. I of course could have read the logs, but I shouldn't have to.

The break occurs because in PG as Vinod pointed out just altering column widths screws up other stuff. I am not sure that my upgrade problem was solely because of this but I couldn't upgrade a 4.5 install to 4.6 and ended up doing the dropdb redo it all from scratch. Of course this was the day of the beta release and some scripts didn't exist at all.

Just please discuss these changes before they are made as sloanspace doesn't run the openacs project. And while they may have good reasons for doing this some discussion should have taken place publically. If no one can upgrade because of a multitude of problems (no scripts, difficult to change functionality, etc), then our audience will just get smaller.

Posted by Jeff Davis on
Back to the task at hand.  Does anyone else see anything that should
be on an OpenACS release checklist beyond what Vinod and I covered?
Posted by Peter Harper on
Having been stung by this yesterday (photo-album), checking that drop scripts work correctly would also be on my checklist.  I know in some cases dropping all data isn't possible because of dependencies etc, but checking that the drop script doesn't leave the datamodel in an inconsistant state or throw any syntax errors would be useful start.
Posted by Bart Teeuwisse on
Make sure that a package can be dropped and re-created. Even after it has been used for a while and (package specific) objects have been created, permission granted and so on.
Posted by Dave Bauer on
The procedure I have been using to update the doc sections is this:

First cvs export -r oacs-4-6-3-final openacs-4 to a temporary directory.

Then I cp acs-core-docs /web/

Finally I add a link in /web/ to the new documentation.

I think we can improve this process when we get running as a branch of the openacs repostiory. We can more easily keep the code base up to date, and the acs-core-docs installed on will be the latest version.

Also as part of the release process it might be a good test to update with the final release code.