Upgrading to SFML 2.0

[MickeyKnox]

After switchin to SFML 2.0, i stumbled over a few issues.
Some things where easy to fix, like Sprite::SetCenter doesn't exist any
more, now it's SetOrigin.

But it took me a while to figure out, that Clock::GetElapsedTime now
returns an int with milliseconds resolution, instead of a float with seconds
resolution.

Is there some sort of tutorial or a collection of issues to consider when
upgrading? I think at least things like the change of Clock::GetElapsedTime
should be communicated somehow...

edit:
And i'm a little confused about the comment on GetElapsedTime:

Its resolution depends on the underlying OS, but you can generally expect a 1 ms resolution.

Isn't it the purpose of SFML, *NOT* having to worry about the underlying OS?

[Lokk]

SFML 2.0 is not released yet, but Laurent often communicate about major API breaks.

See here for the changes in sf::Clock :
http://www.sfml-dev.org/forum/viewtopic.php?t=4864

[Laurent]

Is there some sort of tutorial or a collection of issues to consider when
upgrading

Not yet, but there will be when SFML 2 is officially released.

Isn't it the purpose of SFML, *NOT* having to worry about the underlying OS?

I can't modify the resolution of the OS-specific timing functions, I can only take what they give me

[MickeyKnox]

I can't modify the resolution of the OS-specific timing functions, I can only take what they give me

You can put such details in the OS specific implementation and hide it to the API. I thought this was the general approach.
The timing functions on unix have microseconds resolution. Thus, the API providing milliseconds resolution seems to me, that's what you did.

[Laurent]

In fact what I do is to take a "safe" common resolution for all implementations. All the functions that I use are generally below 1 ms, so yes, in a way we could say that I've hidden the OS specificities -- but things are still not 100% sure