CoinScm - coin-or-foundation/tlc GitHub Wiki

  1. The fact that releases of one project depend on specific releases of all other projects means that when there is a bug fix in some low-level project, such as CoinUtils, that triggers a new release of that project, there has to be a new release of every project depending on that one in order to propogate the fix. This tends to couple development of projects..

  2. The philosophy that only specific combinations of releases should be trusted and that we should treat the whole connected set of projects essentially as one project rather than treating each project as third party with respect to others is not really compatible with the maintenance of separate RPMs for each project. With RPMs, the assumption would be that a new release of the same stable version would not need to be tested, but could just be assumed to work and upgraded as available.

  3. Our current philosophy and the fact that we don't have version numbers included in the names of the libraries also creates problems for users who end up installing multiple projects over time. Because some of them may use different release versions, etc., they can't be installed in a central location and upgraded over time. They have to be kept in separate directories and when new versions are installed, they have to go into a whole new directory. The only alternative is to install CoinAll, but then it is difficult to do any upgrading between releases of CoinAll, which are usually slow in coming.

  4. CoinAll itself is difficult to manage and tends to couple development of the whole set of connected projects even more, which creates a lot work for me and others. It would be better to have some automatic way of selecting a compatible set of versions of the set of libraries of interest and not have to maintain CoinAll in the first place.

I propose that we try to lay out a sequence of baby steps to get there over time.

  1. Many of the problems stem simply from the philosophy we've been living with that only specific combinations of releases can be trusted. I propose that the first step is to decouple development of projects and turn this philosophy on its head. Trunks would be developed against releases of other projects and each project would essentially be treated as third party with respect to other projects. Hence, a release of one project would be assumed to be compatible with any release of a dependent project coming from the same 2-digit stable version. Initially, we could continue to work with externals, but would allow the externals of a given release to be changed without creating a new release. This could be done by hand at first, but as we have time, we could implement a script that would automatically change the externals of all projects depending on a given one each time there was a new release.

  2. After letting the first step settle in and seeing how it works, we could move on to start trying to eliminate externals for the release versions by providing a script that would treat the dependent projects as third party and would figure out what the latest release numbers were and go and get each one of them automatically. We would also have to provide a way of doing an update by using the svn switch command. These scripts should not be hard to write.

  3. This would pave the way to RPMs and .debs for Linux and we could continue to go from there. I guess there's no point in thinking too much beyond that until we see how the first two steps work.