[Pkg-octave-devel] unstable snapshots

[Rafael Laboissiere]

* John W. Eaton <jwe@bevo.che.wisc.edu> [2005-03-15 11:34]:

> I intend to start making a series of "unstable" snapshots of Octave
> that include the new sparse matrix code and which also have the
> gnuplot parser stuff split out from the main Octave language parser.
> It may be a while before this would be considered the "testing" or
> "recommended" version of Octave.  The version number for the new
> series of snapshots will start with 2.9.1 (I hope we are getting close
> to being able to release something called Octave 3.0 sometime this
> summer).

Great news.

> It would be useful to have Debian packages of the 2.9.x snapshots
> because that generally means more people will try them and report
> problems.  But I don't think any of the 2.9.x snapshots should migrate
> to Debian testing until we declare a 2.9.x package as the "recommended"
> Octave version Is there an easy way to keep 2.1.x as the testing
> version?  There may be more snapshots in that series to fix bugs before
> a 2.9.x snapshots can be declared "recommended".

We can fill an RC (release critical) bug report against the package
such that it is prevented from entering testing.  We might also upload
the packages to the experimental distribution, but this would defeat
your goal, which is to reach a wide audience. 

> OTOH, the sparse changes are relatively independent of the rest of
> Octave and they are a new addition, not changes to existing code, so
> maybe the only big concern is what might happen with the gnuplot
> changes.  If so, then it might not be that long before we can call
> 2.9.x "recommended".
> 
> Also, if the numbering goes to 2.9.x, does it still make sense to have
> the Debian package named octave2.1?  If it simplifies things, I could
> also skip to 2.1.90 instead (it seems higly unlikely that we will need
> another 23 bug-fixing snapshots before we can recommend a 2.1.90+
> version).

Dirk has already made provisions for having concurrent octave<n>.<m>
packages in Debian.  I think that his approach can be extended to a new
<n>.<m> version number.  

Instead of octave2.1.90, which is confusing, why not simply octave2.9?

-- 
Rafael