Re: [hatari-devel] Release time for 1.8.1 ?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

I don't think next release version discussion got concluded.
I still propose it to be 1.9.0.

Fixing Hatari snapshot handling before release is too
large change, but IMHO we need to do it before next release.
It can easily be done in such a way that previous Hatari
versions reject new versions correctly.

On torstai 07 toukokuu 2015, Eero Tamminen wrote:
> On torstai 07 toukokuu 2015, Nicolas Pomarède wrote:
>> Le 07/05/2015 00:56, Eero Tamminen a écrit :
>>> Some thing that I'd like to see finalized before release:
>>> - mouse warp
>>> - fopen trace flag

IMHO these should be handled before release, first
is annoying and second one is user API.

I'll handle Fopen next and then maybe mouse warp.


> > > - emulation halt dialog in WinUAE CPU core

Nicolas already fixed this.


> > > - Douglas' DSP debugger & FPU dissembly issues [1]

At least the worst issues don't happen anymore,
so I think this is good enough for .0 release.


> > > - Laurent's asm56000.ttp / GEMDOS HD emu issue

I think this goes after release, I don't have time
to look into it before.


> > > - non-ASCII SDL GUI / filename support

It would be good if somebody would do some
lightweight testing for this (see below).


> > > - update Python GUI for new features

This is done.


> > > More testing is probably required for:
> > > - SDL2 version
> > > - non-ASCII filename support in GEMDOS HD emulation
> > > - GEMDOS HD emu Pexec7 stuff
> > > - Your recent MIDI changes
> 
> Anybody on the list can do testing (only SDL2 item
> needs specific build), it doesn't need to be Hatari
> developers.

I think SDL2 window position issue can be left after
release if Thomas doesn't have time to look into it
as SDL2 support is new and isn't enabled by default.


> For pexec7, it's enough just to try running different
> programs and see whether there are regressions

In my testing everything has worked fine.


> for MIDI,
> running different MIDI programs and seeing whether
> there are regressions/problems.
> 
> For filename support, it's enough to try Hatari on
> directory with weird file names, and see whether programs
> (e.g. replacement file selectors) behave with them as expected.

If somebody on list could look at these,
it would be appreciated!


> > > And I would really like something to be done for the zero-cycles
> > > regression with WinUAE CPU core, especially if this is going to
> > > be .1 release instead of .0 one.  It makes profiler much
> > > less useful with the new WinUAE CPU core version.
> > > 
> > > -> could you look at it e.g. with Laurent?

Instruction cycles should be now checked to be OKish,
but I would like data cache stuff to be fixed too.

If it doesn't get fixed, new profiler support for
data cache would need to be reverted before release
(memory needed for profiling 256 MB TT-RAM is
too much to keep useless data members).

If it gets fixed, I'll still need to update Hatari
manual a bit and remove debug warnings.


	- Eero