Bug 1178876

Summary: FreeType-2.5.5 is available
Product: [Fedora] Fedora Reporter: Alexei Podtelezhnikov <apodtele>
Component: freetypeAssignee: Marek Kašík <mkasik>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: b38617, behdad, fonts-bugs, kevin, mkasik, upstream-release-monitoring
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: freetype-2.5.5-1.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-06 14:55:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alexei Podtelezhnikov 2015-01-05 15:15:41 UTC
Please update.

I am puzzled why FreeType is never updated in the middle of release cycle. Are you sure that backporting fixes is safer? Really?

libpng, libjpeg-turbo, cairo, fontconfig are all fine to update, but not FreeType.

I never ever had any problem with updated versions. You do not seem to have problems updating between releases. So why?

I *know* that changes FreeType introduces changes very carefully.

Please reconsider your policy.

Comment 1 Marek Kašík 2015-01-06 14:26:05 UTC
(In reply to Alexei Podtelezhnikov from comment #0)
> Please update.

I'm plan to do so now since I'm back from holidays and freetype have got to the top of my TODO list.


> I am puzzled why FreeType is never updated in the middle of release cycle.

Because it can introduce incompatible changes which I don't want to get in during stable release.


> Are you sure that backporting fixes is safer?

I don't think that it is safer (could it be?). I actually think that it is equally safe if done well.


> Really?

Really?


> libpng, libjpeg-turbo, cairo, fontconfig are all fine to update, but not
> FreeType.

Freetype is required by quite a lot of packages so I'm quite careful when rebasing it.


> I never ever had any problem with updated versions. You do not seem to have
> problems updating between releases. So why?

I usually rebase freetype in rawhide which is a testing release where users can expect changes but they don't want them in stable release (and me too (except of fixes of bugs of course)).


> I *know* that changes FreeType introduces changes very carefully.

I've looked at changes between versions of freetype in current stable releases (F20 and F21) and their +1 versions and got this list of changes I don't want to introduce into stable releases:

2.5.0 - 2.5.1:
 - The header file layout has been changed. After installation, all files are now located in `<prefix>/include/freetype2'.

2.5.3 - 2.5.4:
 - Some fields in the `FT_Bitmap' structure have been changed from signed to unsigned type, which better reflects the actual usage. It is also an additional means to protect against malformed input.
   - This change doesn't break the ABI; however, it might cause compiler warnings. 
     - But it still changes API!

 - Values of ft_sfnt_* were specified before, they are not now.


> Please reconsider your policy.

I'll check every new freetype whether it is pushable to stable release.


Have a nice day!

Marek

Comment 2 Marek Kašík 2015-01-06 14:47:00 UTC
*** Bug 1178333 has been marked as a duplicate of this bug. ***

Comment 3 Account closed by the user 2015-01-07 14:16:40 UTC
(In reply to Marek Kašík from comment #1)

> I've looked at changes between versions of freetype in current stable
> releases (F20 and F21) and their +1 versions and got this list of changes I
> don't want to introduce into stable releases:
> 
> 2.5.0 - 2.5.1:
>  - The header file layout has been changed. After installation, all files
> are now located in `<prefix>/include/freetype2'.
> 
> 2.5.3 - 2.5.4:
>  - Some fields in the `FT_Bitmap' structure have been changed from signed to
> unsigned type, which better reflects the actual usage. It is also an
> additional means to protect against malformed input.
>    - This change doesn't break the ABI; however, it might cause compiler
> warnings. 
>      - But it still changes API!
> 
>  - Values of ft_sfnt_* were specified before, they are not now.

API changes/compatibility report for the FreeType2 library: http://upstream.rosalinux.ru/versions/freetype2.html