- 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