Re: 3.2.0

[Michael Goffioul]

On Tue, May 19, 2009 at 6:05 PM, John W. Eaton <address@hidden> wrote:
> On 19-May-2009, Jaroslav Hajek wrote:
>
> | as we're approaching the end of May, I think most involved users'
> | expectations (incl. me) as to when Octave 3.2.0 will be out were
> | already exceeded.
> |
> | So here's my offer: I'll start preparing 3.2.0 now. Since apparently
> | few people were pleased by my idea of using a "stable" repo on
> | savannah (already operational, but still empty), I think I'll reuse
> | the established procedure and make the 3.2.x on Thomas Weber's
> | hosting. I'll clone the current tip in the release-3-2-x repository
> | and then make a number of release candidates as usual, hopefully
> | resulting in a stable 3.2.0 release somewhere by the end of May,
> | depending on the responsiveness of our regular builders.
> |
> | The 3.2.x branch will work the same way 3.0.x did, and I'll try to
> | make releases approximately once per 2 months. Using release
> | candidates seemed to be by far the most successful approach, although
> | demanding a bit more from my part, but it seems I'll be able to handle
> | it at least until the end of the year (yeah and we don't expect any
> | newborn children this year :).
> |
> | Further discussions about the development model are still welcome, but
> | right now my feeling is that keeping users stuck with 3.0.x is wasting
> | their time and preventing their better experience with Octave.
> |
> | Are there any objections? Remember, we don't want a perfect release,
> | just a good one in due time.
>
> This is fine with me.  Are there any outstanding bug reports that
> should be handled before we make the release?  The patches I just
> committed should be included in the 3.2.0 branch.  Other than that, I
> think we are in pretty good shape for a release now.
>
> Please tag the point of the branch in the archive on savannah.

If you can wait until I make octave compilable again under Windows/MSVC,
that'd be fine. Otherwise it'll be for 3.2.x.

Main problems are:
- missing xxx_API tags
- incorrectly placed xxx_API tags
- unexpected template instantiations
- compilation of C++ versions of mkoctfile, octave-bug and octave-config

Michael.