> - there is a "main" branch, which contains the "baseline" code corresponding to > the (releases+bug fixes) and there is a > development branch, which is merged from time to time with the main one; > - the bug fixes are put into the baseline version, however > when the changed "baseline" files are commited, they are also tagged > with "-b development" in which way fixes propagate into the development > branch. There is nothing really wrong with this scenario. The only problem is that as soon as the changed "baseline" files are committed, the previous release is not maintained any more ( bugs are fixed in the current "baseline" only, if I understand you well ). Unfortunately, as soon as you add changed "baseline" files, you add new bugs ( while some old may still exist ). And this is the point that I don't like. Anyhow, in the time that passes between two "baseline" version changes, most of bugs in the "current" baseline should already be found and repaired. So, when the "current" version becomes the "old" one, it shouldn't take too much time to maintain the "old" version, too, as most bugs will simply be newly introduced from the new "current" version. I assume here that a new "stable" version comes every half a year, not every month, or week, ... . > 3 independent modules. Fixing the same problem in 3 different versions may > require different patches so I'd consider it to be a very undesirable feature. For me, it doesn't really matter if these three versions are "separated", or kept in the same cvs module. The idea is important, that a "stable" version is maintained ( bug fixes ) at least one year. Again, I assume here that a new "stable" version comes every half a year, not every month, or week, ... ( you might have already noticed, I believe, most people don't need waterworks very much ). As soon as a bug is discovered and the fix is known, one should check if the bug exists also in previous releases, and repair it there, then "merge" this fix into all ( "newer" ) versions that are affected. O.K. It may well be, that maintaining 3 separate modules requires more work than maintaining one "big, common" module with branches. As I say, I don't care, as long as bugs are fixed in "older" releases. > > impossible for our very small team to apply bug fixes to previous versions. You're anyhow in a much better situation then me. > > Because this implies that we will also get bug reports related to, at > > least, three different versions, that we will have to debug 3 versions and Not really. On principle, you would have to debug the "development" version only. Note - if you find a bug and repair it ALSO in PREVIOUS releases, that are affected, then it's not present any more. You WON'T get any bug reports related to it any more. But - the crucial point here is - one repairs newly reported bugs in "older" releases, too. Got the idea ? > > that we have to maintain binaries for 3 different versions (still the majority No, this was not my idea. We are talking about source code, not binaries. I can imagine that you need to maintain only one ( or two ) set(s) of binaries, as it is done now. One set for the current "stable" version, and one set ( maybe ) for the "development" version. As soon as there is a new "stable" version, binaries for the previous "stable" version are "frozen", but ... the source code is still maintained ( bug fixes ). These who take binaries can take the last "stable", or "development" version binaries. Anyhow, I think there will be enough people who will build their's own binaries, so they could "pack" them, after a source code has changed, and upload to root repository - as contributed binaries, for example. This scenario works well in different projects, why not in ROOT ? Jacek.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:31 MET