25 March 2008

Inkscape 0.46 - the stealth release

Now that we are out of the embargo and can talk freely about the release, here is the news item: after over one year of waiting (and a couple of weeks of stealth status), Inkscape 0.46 was released with a load of features.

Why stealth? Between a crappy platform, Windows, which exhibited a bad printing bug (a release blocker) and a tight ass distro, Ubuntu, with its policy of not trusting its package maintainers for package updated, Inkscape developers found themselves in a hard place: to release with a major bug on Windows (where the majority of users are) or delay the release, lose Ubuntu's feature freeze and have no reason to release at all for the following 6 months (about the same happened 6 months ago).
So the "solution" was to release but at the same time not to release: a release a couple of weeks ago, just in time for Ubuntu, but with all the PR embargoed until either the Windows bug is patched or is evident it will not be patched.
At least the release happened officially now.

As a Fedora user, I am content: we have the latest prerelease, pre3, in Rawhide, a build is also available for F8 in Koji for testing purposes, the new version will get in Rawhide and F9 but also (and here our policy and our package maintainers shines compared with other distros) in the current stable, F8.


  1. §1. Nicu, the "PR embargo" policy SUCKS BIG. Are you sure you're not targeting a job at Microsoft? Can't you just assume a bug, or to say that the release for a certain platform is postponed? Oh, and no matter how crappy Windows is, the bug is in GTK, as Windows is not supposed to magically print anything for you, nor is everything a bug in the Windows API -- you know, GTK+ is written by humans too. From a prominent member of the Fedora community (that is YOU), defending the Inkscape PR embargo is unthinkable -- but it just happened.

    §2. What is the package policy of Fedora? 99% of the NON-rolling-release distros don't upgrade a package, but only apply security fixes and important patches (backported if necessary), and they only upgrade to a newer version of a package when there are strong reasons. It looks like Fedora is more lax here. If so, what is that policy? I couldn't find it anywhere!

  2. #1. I am not an Inkscape policy maker, Inkscape policy makers usually work at Canonical. I give the impression that I defend the PR embargo? It wasn't my intention, in fact I planned to talk more strongly about it but the pieces didn't fall in the right places (our, Fedora's, maintainer preferred to not push the updated before the official announcement).

    #2. The (unwritten?) policy in Fedora is that the maintainer can upgrade a package (or at least propose it), if he feel comfortable about that, if enough testing is done and the benefit is important. I believe it is about trust in the maintainers to make the correct judgment and the community to test (we have Inkscape pre builds for F8 in Koji for over a month and those in the Art team use them on a daily basis).

  3. #1. Uh, sorry for being so aggressive in my first post. But yes, I was under the impression that you had nothing against the PR embargo.

    #2. I just discovered how 'undefined/unrefined' is this policy! I guess I'll grumble on my own blog about that soon :-)

  4. Our maintainers can push essentially whatever they want. Soname bumps are frowned upon, and must be coordinated with the maintainers of the affected packages so we don't break dependencies (and if the affected packages are half of the distro, then of course it's not an option ;-) ), but for application packages which don't provide any libraries (or at least none that any other package actually uses), the maintainers can push whatever they want (and I think that's a good thing). Of course, there are things which should not be pushed to stable releases, e.g. new versions of games which can't load savefiles from the old version, but these are things the maintainer should know best!

    Oh, and:
    > 99% of the
    > NON-rolling-release distros
    > don't upgrade a package
    That's why they all suck. ;-)