Forum OpenACS Development: 4.6 release checklist

Posted by Jeff Davis on 10/13/02 10:42 PM

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

2: Response to 4.6 release checklist (response to 1)

Posted by Don Baccus on 10/14/02 05:29 PM

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 ...

3: Response to 4.6 release checklist (response to 1)

Posted by Jeff Davis on 10/14/02 05:38 PM

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.

4: Response to 4.6 release checklist (response to 1)

Posted by Vinod Kurup on 10/15/02 01:24 AM

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 openacs.org 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 techdocs.postgresql.org 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?

5: Response to 4.6 release checklist (response to 1)

Posted by Jon Griffin on 10/15/02 03:45 AM

Vinod,
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.

6: Response to 4.6 release checklist (response to 1)

Posted by Jeff Davis on 10/15/02 07:59 AM

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.

7: Response to 4.6 release checklist (response to 1)

Posted by Jon Griffin on 10/15/02 09:22 AM

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.

8: Response to 4.6 release checklist (response to 1)

Posted by Jeff Davis on 10/15/02 09:36 AM

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?

9: Response to 4.6 release checklist (response to 1)

Posted by Peter Harper on 10/15/02 10:31 AM

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.

10: Response to 4.6 release checklist (response to 1)

Posted by Bart Teeuwisse on 10/15/02 09:29 PM

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.

11: Updating documentation section of openacs.org (response to 1)

Posted by Dave Bauer on 06/05/03 02:09 AM

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/openacs.org/www/doc/opeancs-4-6-3.

Finally I add a link in /web/openacs.org/www/doc/index.adp to the new documentation.

I think we can improve this process when we get openacs.org 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 openacs.org will be the latest version.

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