hi - what is wrong with the "standard" scheme of using CVS for code development?-: - 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. In this scenario one needs to maintain binaries only for one public (baseline+bug fixes) version. There is also no necessity to put fixes into 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. -pasha Fons Rademakers writes: > Hi Jacek, > > altough in principle agreeing with your proposal, it is currently > impossible for our very small team to apply bug fixes to previous versions. > 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 > that we have to maintain binaries for 3 different versions (still the majority > of users installs only the binaries). If ever we would get a few more > (human) resources we could start thinking about the scheme you proposed. > Which indeed makes a lot of sense. > > Cheers, Fons. > > > > Hi, > > > very nice. After easter we will provide a daily updated CVS repository > > > and a cvsweb interface from our machines. This on popular request by many. > > I think I would like to say something additional here. > > I don't ( note : I DO NOT ) care about "daily updated" ROOT sources. > > I do ( note : I DO ) care about DAILY BUG FIXES. > > Current ( actually since ages ) "Root Team" policy is - from time to time > > a new "version" of ROOT is released, containing some "bug fixes" and > > introducing some "new bugs" ( usually called "improvements" ). Moreover, > > as soon as a "new" release is done, "old" releases are not maintained any > > more. If this CVS repository is going to follow this schema ( with the > > difference that a "new version is released" every day ), then ... . > > What I would like to see is a change in the "policy". > > Let's take the 2.21 as an example. As soon as it is introduced in the CVS > > repository it should become a stable "baseline", updated ONLY with bug > > fixes ( as soon as known, of course ). I could imagine that "stable" > > release branches are "packed" as separate CVS modules, that means in > > separate subdirectories in $CVSROOT subdirectory, for example > > $CVSROOT/v2_21 in this case ( forget the /08, it will only harm here ). > > The "development" of new ( 2.22, 2.23, ... ) version(s) should/could also > > be put into the CVS repository, but again "packed" as a separate CVS > > module, for example $CVSROOT/root - note, there is no version, these are > > simply always the current, unstable, daily updated, development sources, > > regardless of the "current version number". > > As soon as the development version is in a "stable" state - it should be > > imported into CVS repository as a NEW module, for example > > $CVSROOT/v2_22, $CVSROOT/v2_23, ... . > > Thus, after some time one would have, for example : > > $CVSROOT/v2_21 ( stable 2.21 ) > > $CVSROOT/v2_22 ( stable 2.22 ) > > $CVSROOT/v2_23 ( stable 2.23 ) > > $CVSROOT/root ( unstable, seems in this case 2.24 ) > > Note - forget the /xx, /yy, /zz from 2.21/xx, 2.22/yy, 2.23/zz. > > Finally, the "life time" of a particular release should NOT be "up to the > > moment" when the new "stable release" is done. It should be maintained > > ( BUG FIXES ONLY, of course ) at least for the next 2 "stable" releases. > > That means, for example, that the v2_21 should be at least maintained > > until the "stable" v2_23 is released. In that moment you could call the > > v2_21 "old", the v2_22 "pro" and the v2_23 "new" ( of course the > > "unstable" root is always the "dev" release ). > > Last, but not least, a file with "known bugs" should be created, > > especially if there are bugs that cannot be fixed ( but possibly, with > > know workarounds ). > > Best regards, > > Jacek. > > P.S. To "import" a complete tree into CVS just do : > > cd $ROOTSYS > > cvs -d /cern/root/CVSsrc import -m "ROOT version 2.21/08" v2_21 CERN root_v2_21_08 > > ( note - the FIRST "v2_21" does the trick, NOT the LAST > > "root_v2_21_08" ) > > cvs -d /cern/root/CVSsrc import -m "ROOT version 2.22/xx" v2_22 CERN root_v2_22_xx > > cvs -d /cern/root/CVSsrc import -m "ROOT version 2.23/xx" v2_23 CERN root_v2_23_xx > > To import the "current unstable" development sources just do : > > cvs -d /cern/root/CVSsrc import -m "ROOT Development Sources" root CERN root_development > > ( note - "root" without version number ) > > I hope it's correct, > > Jacek. > > > > > -- > Org: CERN, European Laboratory for Particle Physics. > Mail: 1211 Geneve 23, Switzerland > E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248 > WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:31 MET