PackageDescription: Epigent Store Configuration Support


Epigent Store Configuration Support

Last published: March 31, 2006 by 'runar'

Defines 3 Classes
Extends 9 Classes

Adds support for using Store "bundles" as a "configuration tool". A "configuration" is understood as the newest versions of the packages that are specified in a bundle. During development developers only publish new versions of the *packages* they change. When they want to catch up with versions of other packages published by other developers, they load a "configuration" of the project's top bundle. Instead of directly loading the versions specified in the bundle, this loading code will check for more recent versions of the packages within the bundle.

When this package is loaded, a new menu item "Load as configuration..." is added to the bundle popup menu. This menu item will only appear on browsers opened after the load.

In ENVY, a configuration was supported by making an "open edition" of an application. Making an open edition of a bundle is not possible in Store. Therefore, developers will usually make a new version of the top bundle for the project when any of the contained packages are updated. This leads to a version bottleneck, as all developers constantly need to update the same top component. Using this tool however, the top bundle will typically be versioned only when a new build is made.

Both bundles and packages are expected to follow the *same* version structure. This structure *must* consist of a sequence of two or more version numbers (numerical identifiers) separated by full stops. An example is "1.2.3.4". The number of numerical identifiers must be equal in both the parcels and packages.

The last numerical identifier for the bundle said to be the "build". The preceding number sequence is the "release". In the example "1.2.3.4", the release is "1.2.3" and the build is "4".

Consider the following setup:
MyProject (Bundle) 1.0
MyDomain (Package) 1.0
MyGui (Package) 1.0

Above, MyProject directly holds on to version 1.0 of MyGui and version 1.0 of MyDomain. A developer changing a GUI will only publish a new version 1.1 of the MyGui package:
MyProject (Bundle) 1.0
MyDomain (Package) 1.0
MyGui (Package) 1.0 and 1.1

After publishing, MyProject still holds on to version 1.0 of MyGui and version 1.0 of MyDomain. If you load MyProject 1.0 using the regular Store tools, you still get version 1.0 of both packages. On the other hand, if you load MyProject 1.0 as a configuration, the load will check if new versions of the packages were published and load these instead.


Support for Multiple Releases and Branches:

Consider the bundles and packages below and their versions (listed behind each entry):
MyProject (Bundle) 1.0.0, 1.1.0, 2.0.0, and 3.0.0
MyDomain (Package) 1.0.0, 1.1.0, and 3.0.0
MyGui (Package) 1.0.0, 2.0.0, 2.0.1, and 3.0.0

There are four releases of the software. This can be seen from the releases shown in MyProject (1.0, 1.1, 2.0, and 3.0). If the developer chooses to load bundle MyProject 2.0.0, then the following will happen:
- MyGui 2.0.1 is loaded, as it is the newest package for the current release (2.0). The code can of course not load MyGui 3.0.0 as this version is for a later release.
- For MyDomain there is no version 2.0.x and therefore an earlier version must be chosen. In these cases, the load code will always choose the version specified in the selected version of the top bundle.
So why does the code load the version specified in the bundle, and not the newest version available? The answer is that this allows working with multiple development streams: There are two earlier versions (1.0.0 and 1.1.0) of MyDomain, but simply loading the newest (1.1.0) can be wrong: Version 1.1.0 is part of release 1.1, and it might be that this code is not meant to be moved up to release 2.0 at all. Relase 1.1 can for example be a service pack for release 1.0 only. When making a service pack like this, the bundles for the newer releases must be updated to contain the nestes version of the packages if the changes are to be included in newer releases.

When modifying old releases of your project, you need to manually move these changes up to more recent releases. In many cases this simply means loading the new version of the changed package into the bundles for the newer releases. Then new versions of these bundles must be published. In other cases you have changed the packages in the newer release. You must then merge the changes as usual.


This tool is in beta. It has been tested with a basic setup containing two packages and a bundle.
Tested with 7.4 only.


Planed Enhancements and Changes:

- Make more fault-tolerant. Now database is assumed to follow the defined rules of version string layout.
- Look at whether the defined rules of version string layout are to strict. Should other rules be added?


Useful Resources:

On the following page, a method for merging packages is described:
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3243260125


License Information:

Released under the curl license:

COPYRIGHT AND PERMISSION NOTICE

Copyright (c) 2006, Runar Jordahl http://www.epigent.com/

All rights reserved.

Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder.