Versions

Both SketchApps and the apps it supports can be expected to evolve. So, we need a convenient and robust way to handle new versions. Like all of SketchApps, this is a Work In Progress...

Initial Approach

My initial approach to version management was very simple.

Only a few sets of software were involved and each one had a version file. So, for example, .../SketchApps/CFCL/Public/Admin/Version contained the version information for CFCL's public distribution:

; Version - version file for CFCL_Public
...
time_gmt=2011-04-27 00:26Z
time_lcl=2011.0426.172646
;
version=0.2.1

An installer can use the version number to tell whether a given app (eg, CFCL/Public) should be replaced. This scheme allows both the framework and the individual apps to manage their own version information.

Dependency hell

Unfortunately, this approach didn't handle code dependencies. Consider the following scenario:

  • Joe User installs some apps and a common library.
  • New versions of the apps and libraries are released.
  • Joe upgrades some (but not all) of the apps.
  • API changes cause some other apps to misbehave.

Although this particular scenario could be avoided (eg, don't break APIs, don't do partial upgrades), there are many other ways that things can go wrong. This is far from being a new problem:

Dependency hell is a colloquial term for the frustration of some software users who have installed software packages which have dependencies on specific versions of other software packages.

-- Dependency hell (WP)

There are various ways to deal with this problem. For example:

  • Some GNU/Linux package managers resolve clashes
    and download needed libraries automatically.

  • Bundler creates archives that include needed RubyGems,
    based on a file of dependency declarations.

Bundler and RubyGems could (and probably should) be used with SketchApps, but this will require some experimentation and development. In the meanwhile, SketchApps developers should minimize code dependencies (eg, shared libraries).

Case in Point

The initial releases of the CFCL_Public and Igloo_Public SketchApps used the .../SketchApps/_All directory tree for common code, saving 4.7 MB of storage:

Size  File Path
====  =========
4688  _All/
4548  | External/
   8  | | Admin/...
4524  | | Code/
4480  | | | jQuery/...
  44  | | | Ruby_lib/...
  16  | | Image/...
 140  | Framework/...
  20  | | Admin/...
 120  | | Common/...

Although this seemed like a good idea at the time, it requires all SketchApps on a given user's computer to share the same libraries, APIs, etc. This is clearly unsustainable, given that we will need to update both internal and external libraries.

Fortunately, there is a reasonable compromise: move the library directories (eg, External, Framework) under the SketchApp author's directories (eg, CFCL, Igloo).

This requires Individual authors to keep library requirements consistent, or at least under control. So, for example, the Igloo/Public (ie, Product Connect) plugins all use the same set of libraries, but the CFCL/Public ones can move to a different set, if need be.

Implementation

We can't simply eliminate the common library directories, because this would cause any apps that depend on them to crash. However, there is a reasonably graceful alternative:

  • Put copies of the library directories into each new app.

  • Leave the old library directories in place for now.

  • After a while (eg, a year), remove the old library directories,
    displaying an "upgrade now" dialog on any attempted use.


This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

Topic revision: r10 - 07 Mar 2012, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email