Streamlined Loading

From a clean image, we need to load Store and connect to the database. We save this image and keep it for loading our application in the future.

Our application consists of two distinct areas - base code (about 3000 classes) that seldom changes and our application code (about 1000 classes) which changes frequently. We have one bundle which contains all base code. For our application code, we have a bundle which only has prerequisites of other bundles to load. This allows developers to change the bundles in their area without a whole lot of merging necessary. To make the final build, we change the versions listed in the prerequisites and re-publish our main bundle (even though we may not have all the other bundles loaded). When we load that bundle again, we'll get all the right code.

The one thing about this process which is painful is the prerequisites editor for bundles. It is simply a text editor on an array of arrays of strings. Small typos could cause load failures. We REALLY need a better editor for this.

________

Comment from Mathieu van Echtelt to above:

In Envy you had two lists. Prerequisites-list, which was simply editible (adding, removing items from list by clicking) and dependents, which was automatically generated.

In Store their are two less convenient ways to accomplish the same: 1. Pundle sorting in list. It would be more flexible and robust if knowledge of structures is stored within the Pundles. 2. Text editing in propeties of a Pundle. Good solution but not userfriendly implemented yet. Difficult to see structure overview. Difficult to edit.

________

Ulli Wenk (wenk@hinz.de):

We have an other strategy:

0) We ensured (by simple modifications of setting blessings and publishing) that there is for every pundle a unique integration-ready version.

1) There is one central bundle containing all subpundles of our application in ANY version (at first it was the (most recent) integration-ready version).

2) We've written a load-method, doing the following:

Load the (most recent) integration-ready (= i-r) version of all subpundles of the central bundle, i.e. trace thru (contained items (=CIs) of) the central bundle and:

a) if a CI is a bundle that has a more recent i-r version, than unload all no more needed subpundles and continue the process with the contained items of the more recent i-r version

b) if a IC is a package load the most recent i-r version.

3) If a developer wants to publish a package s/he merges all from the i-r version and publishs as i-r (our default)

4) If s/he has to add a new bundle B into a superbundle A, he has to edit the specification of A and to publish A as i-r.

Thus every developer can load the most recent sources of the whole team and can publish at every time he wants. Cause we are checking (in the moment of publishing in DB) that your package version is child of the last i-r, the problems of two parallel publisher does not occur. The last of these two publisher gets a message that there is a more recent i-r version of the parent package where from he started before merging.