New Release Process

The release is planned in advance and noted in the project calendar.

Warning are added to the homepages of affected apps.

A notification email will be sent to known users on the Monday before the release or at least a week before.

The apps can be packaged in two ways

• in exide with application/download
• MUCH MORE RELIABLE, but still problematic in exide with application/syncronize and then ant on the destination directory in the server TEI Publisher has a page about it

1. Issues which are resolved in the candidate release are added to a milestone with a release number. To set up the local copy of the app read here

2. a new release is announced with a week advance and planned in the common calendar

3. all changes made should be recorded in notes to be published with the release of the code

4. an email annonuncing the freeze will be sent Friday morning

5. changes freeze happens on a Friday at 12, so that deployer has the time in the afternoon to update with the latest data the candidate release before loading it to the server

   1. data is pulled from all the repos
   2. data is moved to a local directory data which contains the main project data directories
   3. the repos in git are capitalized, while in the app not. the directories and files and only those from git are copied to the data directory for the new release
   4. the data temporary directory is uploaded to the candidate release

6. If the release includes an upgrade of exist-db to a new stable version, this will require probably one extra day and will begin on Thursday at noon, rather than Friday.

7. Thoroughly test the new app with the latest data, download it, remove it and reload it in the local version before closing the new candidate release.

8. This version is then uploaded in place of the previous version of the app on the server

   1. save the current online version in the app backups
   2. trigger a backup
   3. remove the current app from package manager
   4. install the new release of the app from package manager
   5. check that the system/repo contains the xar files. this is needed by xsl-fo transforms to retrive fonts
   6. copy the collection.conf into db/system/config/BetMas and index
   7. run registerRESTXQ.xql to register all the RESTXQ modules to the restxq.registry

9. alternatively, if the packaging does not work, the files can be updated one by one, importing them in the app already running online. this will create problems with the fonts which are called from the repo collection and will have to be done for all the files.

10. the warning are removed from the homepages of the apps

11. The update happens on Monday morning, but not every monday, only when significant change justifies a new release

12. The newly installed app is then uncompressed, modules, xslts, templates are copied to the app repository and the commit will contain a release note detailing all changes.

13. An email is sent to known users notifying the release, with a link to the release notes and a link to the tagged issues to trigger the following and last testing phase)

14. Users will have to check the issues closed under the release milestone (testing phase) on the Monday morning.

15. if they are not happy with the result they should reopen the issue and assign it to the next release milestone Changes will not be seen in the live app until the new release happens. Your data uploads instead will be immediately visible, if the syncing goes well

16. run documentation app to produce documentation of all the available functions and modules