Re: [Gcl-devel] 2.6.1

[Vadim V. Zhytnikov]

Camm Maguire ?????:
> Hi again Vadim!  One other clarification---
>
> "Vadim V. Zhytnikov" <address@hidden> writes:
>
>
> > Camm Maguire writes:
> >
> > > Greetings, all!  You may have noticed the recent CVS activity.  Just a
> > > quick summary here:
> > > 1) ftp.gnu.org is *still* down, so I'm proceeding with a Debian
> > >   package release to see where we are.
> > > 2) Stable is now numbered 2.6.x, and unstable 2.7.x.  The debian
> >
> >      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > >   package can build simultaneously installable gclcvs and gcl
> > >   packages to help with our development once this gets settled.  3)
> > > axiom builds with 2.6.1 installed separately.  I have a prototype
> > >   Debian package to release to unstable for testing shortly.
> > > 4) Sizes increased, but a bit more work needs to be done here I
> > > think.
> > > 5) quite a few other changes, check the debian/changelog.
> > > take care,
> > > =============================================================================
> > > gcl (2.6.1-1) unstable; urgency=low
> >
> >        ^^^^^^^^^^^^^^^^^
>
>
> This 'unstable' refers to the Debian unstable distribution.  All gcl
> releases uploaded to Debian must first pass through unstable and
> testing before they enter the 'stable' Debian dirstribution, which
> should be released sometime in Dec.
>
> Our 'unstable' means a CVS snapshot which we do not intend to install
> as a tarball on ftp.gnu.org.
>
> In any case, I'm open to suggestions on all such matters.
>
> Take care,

I totally agree with new numbering scheme.  But I venture
to suggest a bit different strategy concerning the release
time (moment) and exact meaning of even and odd branches.
Now we work on still not yet finally released 2.6.1 - so let it be
(BTW, why not 2.6.0, am I missing something?).
But, IMHO our numbering scheme should look as follows:

1). We work on 2.5.X as unstable development branch.

2). At some moment we decide that 2.5.854 is ready to
be released as stable version and we rename it as 2.6.0.
New tags 2_6_0 and 2_7_0 are created in CVS (actually
2_7_0 may be forked earlier).

3). And here is my main point. We proceed to work on 2.7.x
We _do_ _not_ _work_ actively on 2.6.0.  Subsequent 2.6.X X>0
releases are for serious bugfixes only and maybe for some
backports from 2.7.X development branch.

How about this?

Best wishes,

Vadim


--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>