NewRepositoryLayout
The following new repository layout is proposed:
-
trunk/: main development trunk
-
trunk/Timba: core MeqTree system, without Waterhole, without Frameworks
-
trunk/Frameworks/Cattery: core Python frameworks: Meow, Siamese, Calico, LSM, Lions
- trunk/Frameworks/Cattery/Meow
- trunk/Frameworks/Cattery/Siamese
- .. NB: other frameworks reside & develop in the Waterhole (as long as they are supported by the author only); once they merit inclusion in the core system (which means we have to test/release/support them centrally), we move them into trunk/FW.
-
trunk/casarest: casarest package
-
trunk/MakeMS: makeMS package
-
trunk/Waterhole: Waterhole free-for-all area (hands-off, unsupported and unreleased)
-
doc/: documentation
-
doc/Timba/doc: system documentation (officially maintained, released and supported)
-
doc/Timba/Presentations, doc/Timba/Notes, etc.: free-for-all for presentations, papers, etc.
-
branches/: experimental branches
-
release/: release branches. Read-only! Modifications to a release (which are bugfixes only, anyway) are made by copying the release branch into an experimental branch, modifying code, and then once it has been tested, copying it into another (patched) release branch.
-
release/Timba: core package releases
- release/Timba/1.0.p0: Timba release 1.0
- release/Timba/doc-1.0.p0: corresponding documentation release
- release/Timba/Cattery-1.0.0: corresponding Cattery release ("baseline release")
- release/Timba/Cattery-1.0.1: Cattery 1.0 sub-release 1
- release/Timba/Cattery-1.0.2: Cattery 1.0 sub-release 2
- release/Timba/1.0.p1: Timba 1.0 patch release 1
- release/Timba/Cattery-1.0.3: Cattery 1.0 sub-release 3
Timba release version numbers are X.Y.pP, corresponding to major X, minor Y, patchlevel P. (NB: I propose we use the name "Timba" to refer to the core MeqTree releases, i.e. without frameworks.) Patch relases are for bugfixes only. Any change to functionality is at least a new minor version release. Really big changes are a new major version release.
Cattery release version numbers are X.Y.Z, for major X, minor Y, subrelease Z. It is anticipated that Cattery releases will be more frequent than Timba releases, hence the need for subreleases (i.e. Z is going to change often in between Timba releases.) Cattery-X.Y.Z is certified to work with Timba-X.Y.pP for any combination of P and Z. Any change to Cattery requiring new functionality in Timba automatically forces a new minor Timba release. Conversely, every time we make a new minor Timba release (going from X.Y to X.Y+1), we release new "baseline" Cattery-X.Y+1.0 (which could even be identical to the previous Cattery, X.Y.Z, but it keeps the X.Y version numbers consistent). Should we ever find ourself with a user that is stuck with an old version of Cattery for some reason, but still needs an urgent bugfix, we can (as an exception) make a patch release of Cattery called Cattery-X.Y.Z.p1, etc.
We ship two packages, tentatively called Timba and Timba-Cattery. The first one is the core system, the second one is the Cattery.
The core system will generally need to be installed/upgraded by a sysadmin (package managers can also install things locally in a user's home directory, but this is not an option for a lot of astronomers as far as large binary packages -- which Timba will be -- are concerned.) Cattery, on the other hand, is just a bunch of Python scripts and is therefore (a) small, (b) can be easily installed by the user locally. Therefore, we anticipate that sysadmins will install/upgrade Timba releases and baseline Cattery releases (in a systemwide location). The users will then have the option of downloading and installing new Catteries in their local directories, and falling back on the systemwide "baseline" Cattery when things go wrong.