"We are very pleased to announce this release, the first major update to cairo since the original 1.0 release 10 months ago. Compared to cairo 1.0, the 1.2 release doubles the number of supported backends, adding PDF, PostScript & SVG backends to the previous xlib/win32, and image backends."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-30
Member since:2005-09-01
The way OSS projects work the whole sw life cycle out is a little bit different. It's a spiral like-model where every previous version can be consideted a prototype for the following version.
There is not an upstart design and architecture but continous refinements between releases based on experience. Of course, at some time the mass of current users starts depending on the project's stability, settles down with presently working design, demands compatity.
Finding a correct ballance between opportunity of making dramatic improvements and satysfying larger user base is quite hard, but responsive and experienced mainainers know how to choose best moment to announce point release.
This part of lifecycle in commercial products happens behing closed doors, before first release, you it's not possible to compare OSS and commercial release strategies.
Member since:2005-07-30
Member since:2005-07-06
And you're bitching about .80 breaking with .10 - oh, should I start bitching that Microsoft broke compatibility between .NET versions 1.x and 2.x? should I start bitching because Microsoft is breaking compatibility between Windows XP and Vista?
Please, there are perfectly valid reasons, and the Gstreamer is hardly a project I would called 'ready for prime time' no matter how much the halfwitts over at GNOME embraced it.
Member since:2005-07-06
If you can plan for all API changes you'll ever need ahead of time, then your software probably doesn't do anything interesting. Breaking compatibility once in awhile is a hell of a lot better than what Microsoft does, which is to slaveishly maintain compatibility so much that huge amounts of workarounds get written to avoid breaking anything.
Member since:2005-07-06
As it seems, you never really worked on big project, did you?
ABI/APIs can only sit still if the base requirements stay still. Once the requirement change, even by a bit, ABIs tend to break.
Now, you can maintain compatibility by creating the following code:
if (old_api_client)
do_things_old_api_style();
else
do_things_new_api_style();
But it'll complicate your code by an order of magnitude and make it barely
readable. Oh, and even worse, it'll will make your code more prone to bugs and security
exploits.
You -only- need API/ABI compatibility is your library is being use to run legacy closed source applications that cannot be modified and compiled to use the new library code... but in the OSS, we don't have that, do we?
BTW, haven't you given up on posting the same point, over and over again?
Member since:
2005-07-06
Have you ever taken the time as to WHY some projects break API/ABI compatibility. Instead of spouting off senseless crap, how about investigating the decisions behind any changes.