Thanks Michael.
The 0.8.0 release was really only internal. We never had such a public
release. I think it represented something like GMP 4.2.1 + Gaudry
patches + intel format code.
Bill.
2009/2/27 mabshoff :
>
>
>
> On Feb 27, 9:49 am, Bill Hart wrote:
>> Hi Brian,
>
> Hi,
>
>> If Michael set
On Feb 27, 9:49 am, Bill Hart wrote:
> Hi Brian,
Hi,
> If Michael sets up a 1.0.0 milestone on trac, then we'll just close
> tickets when they are fixed. What you did was actually right.
I set up 0.9.1 and 1.0 milestones - see
http://trac.mpir.org/mpir_trac/roadmap
I also closed the 0.9
Hi Brian,
If Michael sets up a 1.0.0 milestone on trac, then we'll just close
tickets when they are fixed. What you did was actually right.
With regard to the dive_1.as bug we should open a trac ticket for this.
We don't seem to use dive_1 in the linux x86_64 code. So I think this
issue only af
On Feb 27, 5:12 pm, mabshoff wrote:
> On Feb 27, 9:07 am, Bill Hart wrote:
>
> > Hi Brian,
>
> Hi Bill,
>
> > I think it is much better if we don't close trac tickets until the
> > release is made. That way it is easy for someone writing the NEWS file
> > to see what has changed for this relea
On Feb 27, 9:07 am, Bill Hart wrote:
> Hi Brian,
Hi Bill,
> I think it is much better if we don't close trac tickets until the
> release is made. That way it is easy for someone writing the NEWS file
> to see what has changed for this release. Instead simply prepend
> [done] to the title of t
Having said that, if all tickets were assigned to a milestone, we
could get away with closing tickets. But at present we have no
mpir-1.0.0 milestone in the system. Of course then we would have to be
careful to assign bug fixes such as the ones I just described, to no
particular milestone before c
