2 Registration

Let us call a library using default versions a "dynamic" library, while a library using -directly or indirectly- only explicit version numbers a "static" library. Once a library is registered, a tool has to replace all implicit default versions by explicit versions, yielding a static library. This is needed in order to guarantee that the functioning of the library is not destroyed when (the latest versions of) imported libraries change. This also leads to the requirement that each registered library must specify a version number (in order to be accessible by explicit version number).

One may think that this is a rather conservative regime and propose to always use dynamic libraries, with the possibility to change to safe static libraries wherever this does not work. The question behind the scene is: who has the responsibility for obtaining a current but still consistent version of a library? In experimental environments, it may be the case that the user of a library tries to update a library on his/her own by using a dynamic version. I an industrial environment, it will be necessary to work with static versions of libraries only, giving the responsibility of having a current but still consistent version to the library maintainer. A typical library development cycle would be the following:

1. Check out a set L of libraries from the central repository, i.e. make a copy into the local workspace. During this process, a rejuvenation procedure is called in order to get the latest versions of the libraries. Usually, the latest versions of the libraries in L will be selected. Furthermore, it will be sensible to replace all references within L to specifications from other libraries (within or outside L) by references to the latest version⁴ (References within) libraries outside L are not changed at all (this would be the responsibility of the maintainers of those libraries).

   As a result of the rejuvenation, the libraries in L may be ill-formed, or, if well-formed, may fail to have the intended semantics. Thus, the library maintainer of L now must try to get things compatible, before (s)he can start with his proper goal of updating the library (say, by adding some new features etc.).

   If it turns out to be too difficult or impossible to get things compatible using the latest versions, other, earlier versions have to be used. There are sophisticated tools that can perform database queries consisting of items like "the latest version", "the version at a given date", "the latest version containing this text" etc.). In particular, the "third party problem" (see the next subsection) can lead to the necessity to modify libraries outside L. In any case, I would suggest that more sophisticated queries that cope with these problems are a tools issue. In the language, it suffices to have just the possibilities to choose the latest version or an explicit version.

2. Work on the checked-out (and therefore local) copy of L by fixing bugs, adding new features etc.
3. When other libraries have changed in the meantime (this may happen in particular if different people simultaneously work on different libraries within one project), make a checkpoint. This means to save the current, hopefully consistent, state. Then, invoke the above rejuvenation process again. If this fails, it is still possible to return to the checkpoint.
4. When a stable new version of L has been obtained, check in (or register), i. e. transfer the local copy to the global repository, making it thus visible for others.
5. There may be different degrees of checking in, for example, a version may be marked as "working", "public", "registered", "official release' etc.