Forum OpenACS Development: Re: Naming Conventions for sql upgrade scripts

Collapse
2: Re: Naming Conventions for sql upgrade scripts (response to 1)
Posted by Andrew Grumet on 02/26/04 02:39 PM
Okay so the older, 1.0 era upgrade scripts in that directory are also incorrectly named.  Ugh.

As for mine, the task now is to get the version numbers straight and make sure the .info file is set correctly for release.

I understand that we are getting ready to cut version "2.0", so the new file name should be something like

/sql/postgresql/upgrade/upgrade-2.0xxx-2.0.sql

Okay, so the question is, what is "xxx" above.

The dotlrn.info file at the head of the dotlrn-2-0 branch says "2.0a3".  The latest tarball available at https://openacs.org/projects/dotlrn/download/ is "2.0.0rc1".  The CVS tree has many other tags including one for "rc2".

If we want to keep APM happy, we should use the value from the .info file.  So...

/sql/postgresql/upgrade/upgrade-2.0a3-2.0.sql

Any objection?

Collapse
3: Re: Naming Conventions for sql upgrade scripts (response to 2)
Posted by Joel Aufrecht on 02/26/04 04:01 PM
What if we find a new bug that requires another upgrade script?

I think the better practice is to never end an upgrade script with the release version; instead just use b# until infinity.    The underlying principle is that the author of the code never gets to say that it's release-worthy - that's the job of Quality Control.  So the author can only pump out release candidates; eventually the accepted release candidate becomes the release.  But the only renumbering that happens then is in the docs and .info files, which the release manager handles.

But this practice isn't followed by most of the scripts, so ....

Collapse
5: Re: Naming Conventions for sql upgrade scripts (response to 3)
Posted by Andrei Popov on 02/28/04 01:48 PM 
> I think the better practice is to never end an
> upgrade script with the release version; instead
> just use b# until infinity.

...or add a fourth sequential numeral in version number like:

	foo-5.0.3.12345

that would indicate patch/upgrade level. To make it more explicit, it can be separated with an underscore or a hyphen instead of a dot.

Yet another alternative is indeed to use datestamps, but then an 8-char CCYYMMDD format should be used (ensure proper sorting and is Y2K compliant :)