search

source-foundry / ttfautohint-build

Build ttfautohint from source on Linux and macOS platforms
MIT License
27 stars 12 forks source link

Versioning of ttfautohint-build #2

Closed chrissimpkins closed 6 years ago

chrissimpkins commented 7 years ago

How to version this repo vs. ttfautohint version when the scripts change here?

I currently have a tag on this repo at v1.7 in order to maintain consistency with the ttfautohint binary built with it (and to generate a Github release). How do we version changes to the scripting here vs. on the build product?

lemzwerg commented 7 years ago

I don't think that the build commands for either FreeType, HarfBuzz, or ttfautohint will change significantly. If ever necessary, there could be a test for minimum versions support by ttfautohint-build.

chrissimpkins commented 7 years ago

I don't think that the build commands for either FreeType, HarfBuzz, or ttfautohint will change significantly. If ever necessary, there could be a test for minimum versions support by ttfautohint-build.

The version string for ttfautohint (and potentially version strings for each of the dependencies) will change with each new release though. So the script will change and require some maintenance each time you push a new release of ttfautohint.

# The library versions.
FREETYPE_VERSION="2.8"
HARFBUZZ_VERSION="1.5.0"
TTFAUTOHINT_VERSION="1.7"
lemzwerg commented 7 years ago

Well, yes, but the old versions won't disappear...

chrissimpkins commented 7 years ago

Sorry, not sure that I understand. What I am after is a strategy to connect this repo to your ttfautohint release source across any version of the ttfautohint source files (beginning at ttfautohint v1.7 release since that is where we are starting).

I currently have https://github.com/source-foundry/ttfautohint-build/commit/75ec88e16f7e5cbb22331c1712c8c79db5e37f74 tagged as v1.7. When we make the changes to the scripts here we will have a new commit for the ttfautohint v1.7 release and we will want to associate a ttfautohint-build release with it (I think? Or do we just instruct users to build directly from the current master branch with assumption that they receive current release of ttfautohint with all necessary build changes incorporated as of HEAD of master?). I can move the v1.7 tag to the "acceptable/approved" commit anytime we change anything in the repo that would influence the build process if we go with tags/releases though that seems to be a bit of a hack...

lemzwerg commented 7 years ago

I mean: It's not necessary to have a direct connection between recent ttfautohint, Freetype, and HarfBuzz releases and ttfautohint-build – the goal is primarily to create something that builds reliably for source-foundry, right? The currently selected versions do build fine...

On the other hand, it might be nice to add a second 'mode' (similar to the behaviour of ttfautohint withint Homebrew) that uses HEAD of all three repositories. Doing so, however, would need much more tools...

chrissimpkins commented 7 years ago

the goal is primarily to create something that builds reliably for source-foundry, right

Actually, my goal here is to release an approach that builds for anyone out there, not just our project(s). I can imagine use cases for other typeface development teams where build from typeface source is beneficial and this often requires ttfautohint as part of the ttf compilation and post-compile modification workflow. I am attempting to support that in a very general way with the script that you contributed to the Hack build.

chrissimpkins commented 7 years ago

My thoughts about how users would approach it are fleshed out in the README PR:

4

lemzwerg commented 7 years ago

Actually, my goal here is to release an approach that builds for anyone out there, not just our project(s).

No disagreement :-) However, this doesn't mean that you have always to use the most recent versions of the affected libraries. I think my arguments still hold.

chrissimpkins commented 7 years ago

Yes, agree completely! No intent to be at the tip of HEAD in any dependency or ttfautohint. just wanted to establish consistency between the release version of ttfautohint and the 'versions' displayed to users here. We can find a strategy that is explicit so that they know what they are getting.

We don't want to display ttfautohint-build-1.7.1 during the build process when they are building ttfautohint 1.7

chrissimpkins commented 7 years ago

@anthrotype removed and re-pushed the v1.7 tag to your most recent commit to maintain consistency with the ttfautohint version. Don't have a better approach at the moment. If you have thoughts let me know.