On Thu, Nov 30, 2006 at 02:32:03AM -0800, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Thu, Nov 30, 2006 at 08:40:02AM +0100, Mike Hommey wrote: > > > I'd like to upload a new upstream version of libxslt, which is only a > > bugfix released: > > > Upstream changelog reads as follows: > > - entities within attributes (William Brack) > > - Python detection problem (Joseph Sacco) > > - in-scope namespace bug (Mike Hommey) > > - Result value tree caching bug (William Brack) > > > All of which, except the python detection problem, have already been > > applied to 1.1.18-2 and -3... which means there won't be an shlib bump. > > I think it's better to have 1.1.19 in etch than an 1.1.19-looking > > 1.1.18 for user understanding. > > I don't think cosmetics are a particularly compelling reason for an update > of a core lib this close to release, especially when the update is /not/ > wholly cosmetic. What is the "python detection" fix that's included here?
The "python detection" fix is a single line change in configure.in for the PYTHON_SITE_PACKAGES variable, which is not even used during build. For the rest, they are nasty bugs that cause FTBFSes on other packages using xsltproc to generate documentation and may have other implications. These bugs are all present in the version currently in testing. So yes, the difference between 1.1.18-3 in sid and 1.1.19-1 which is ready to upload is entirely cosmetic, and the difference between 1.1.18-1 in testing and 1.1.18-3 waiting for rubrica to stand aside to go in is RC fixes. But if you prefer to release etch with either a broken version or a version which number may lead users to believe it's broken, well, that's your call... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
