Deploying updated libraries (was Replacing Omnis VCS with SVN/Git type repository)
here it is. this archive was made in 2015 .. and given to a few people. its got some ‘good enough’ documentation with it …
feel free to adapt, use to your own needs.
the restarter alone .. is a good way to tell omnis to completely restart itself periodically if you want to do that (as graham points out — for their web services).
see you at the third annual users conference
> On Jan 2, 2018, at 8:10 AM, Alex Clay <firstname.lastname@example.org> wrote:
> On Jan 2, 2018, at 09:52, Graham Stevens <email@example.com> wrote:
>> How are you assigning (and reading) the build number of your libraries? I have been thinking along similar lines, perhaps, in our case, using the SVN revision.
> We write a simple build_number.txt with each build from Jenkins. We track these number in a separate database to ensure a unique value.
> I like the idea of a configuration file, perhaps with support for including an entire directory. We could also add support for including remote files, such as libraries hosted on Github. Add some semantic version tagging and presto – true package management for Omnis. (As if it’s _just_ that easy!! 😉 )
> I’ll see if I can integrate our two approaches this week and offer a PR to your project. I’m working on switching our Mac deployment to use ~/Library Application support which requires testing our app_loader on macOS, so the timing is good.
> Our app_loader.lbs will perform a runtime update of running libraries so don’t restart Omnis. However, this doesn’t handle reloading xcomps, so Doug’s python reloader is a good companion project.
> Manage your list subscriptions at lists.omnis-dev.com
Manage your list subscriptions at lists.omnis-dev.com