Merging a New Release

This page documents the process of retrieving the latest SQLite and merging it into the OpenVMS code base.

...pointer to blog about setting up NFS...

The first step is to create a new issue that covers the merge of the latest SQLite source code with the existing SQLite for OpenVMS code base. For the examples in this wiki entry we will use issue #19, which covers the merge of sqlite3 3.7.16.0 into the existing code base, which is derived from 3.7.15.2. This issue should be marked as an enhancement.

The first step is to create an orphaned branch to commit the latest SQLite source code into. Do this by executing the following commands:

git checkout master
git checkout --orphan sqlite-3.7.16.0
git rm -rf .

Then, construct the URL of the pre-processed source archive from the SQLite site, the URL can be constructed like so:

For SQLite 3.mm.nn[.ee]

http://sqlite.org/yyyy/sqlite-preprocessed-3.zip

yyyy  = the year of the release
mm    = major version number
nn    = minor version number
ee    = edit (00 if not present)

So, for SQLite 3.7.16, the resulting wget command would look something like:

wget http://sqlite.org/2013/sqlite-preprocessed-3071600.zip

Which would be followed by the remaining commands to commit the code to the repository.

unzip -jaa sqlite-preprocessed-3071600.zip
rm sqlite-preprocessed-3071600.zip
rename 'y/A-Z/a-z/' *
git add .
git commit -m "Load official SQLite 3.7.16.0"

Once the code is in the repository, merge in the master branch which consists of the previous official stable release from SQLite, plus the OpenVMS-specific modifications.

git merge master

This is likely to produce a number of conflicts that will require human intervention to correct. These are usually quite simple to resolve, just slightly time consuming. The only places where a lot of attention must be paid is source modules that have OpenVMS-specific changes (shell.c is a good example).

After the merge has been completed and committed, switch to the OpenVMS system and test the build to see that it at least completes without error.

$ MMK CLEAN
$ MMK

If the build does not succeed, investigate and apply appropriate fixes. Once the build works cleanly and the software runs, it is time to merge the new branch back into the master branch and tag it for release.

git checkout master
git merge sqlite-3.7.16.0

Once merged, remove the old branch and push the changes back to Github.

git branch -D sqlite-3.7.16.0
git push origin

With the new release now available at Github, go to the project page and click the 'release' link. This will take you to the Releases page. From there, click "Draft a new release" and fill out the fields, like so:

Tag version: V7.16
Release title: SQLite3 for OpenVMS V7.16
Description: SQLite3 for OpenVMS V7.16 (based on sqlite 3.7.16.0)

Obviously, changing for the version being built. For full details on SQLite version numbering, read SQLite for OpenVMS Version Numbers.

Lastly, it is important not to skip too far ahead between releases as it may become very difficult to consolidate changes and determine what it correct. It is far better merge the releases incrementally, which will also allow the OpenVMS version to remain in sync with the latest official SQLite. Join the sqlite-announce mailing list.