[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] 2.6.1

From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] 2.6.1
Date: Sat, 06 Sep 2003 19:03:19 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.4) Gecko/20030630

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
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 V. Zhytnikov


reply via email to

[Prev in Thread] Current Thread [Next in Thread]