Greetings!
"Vadim V. Zhytnikov" <address@hidden> writes:
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?).
I released a 2.6.0 snapshot to the Debian experimental distribution
some time ago, so we have to start from 2.6.1.
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).
This is great except for the fact that 2.5.1, 2.5.2 and 2.5.3 were
stable releases. I think it would be confusing to go back and call a
2.5.x 'unstable'. What we've essentially done is rename 2.5.4 to
2.6.1, and CVS HEAD 2.6.0 to 2.7.0. We had already forked a CVS
unstable off of 2.5.x long before we thought about this numbering
scheme, I think.
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.
I agree with this completely, and also agree that we're currently
modifying 2.6.1 too much. I hope this will be very short lived. The
problem is that a number of major bug fix category changes have piled
up and taken precedence. I think we're just about at the end of this
though. This is somewhat akin to the linux kernel process. Once a
stable '.0' release is made, most of the work still goes into chasing
down bugs newly discovered on release. Unstable is forked earlier,
and moves very slowly until the stable becomes really stable. Then
after a few minor point revisions, work proceeds primarily on unstable
and the stable series is only rarely touched if at all.
The other problem we've been having is that we've been getting a lot
of debugging/testing help via the autobuilders. We need a way to
release frequent binary CVS snapshot builds, as we've been doing in
the cvs subdir of the ftp site, without interfering with our stable
binary builds. I think we've finally got this. I've reworked the
Debian package so that unstable and stable builds can exist on the
same system simultaneously. We'll have two sets of packages, 'gcl'
(stable) and 'gclcvs' (unstable). We'll mirror frequent binaries of
the latter under the cvs subdir of the website as before, and create a
separate mirror for the stable builds under a subdir called stable.
This way, maxima, acl2 and axiom can Build-Depend on gcl, and we can
release gclcvs as frequently as we'd like for testing purposes without
breaking the builds of these apps.
Comments/suggestions always welcome.
Take care,
How about this?
Best wishes,
Vadim
--
Vadim V. Zhytnikov
<address@hidden>
<address@hidden>
_______________________________________________
Gcl-devel mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gcl-devel