Noto version

[frispete]

Hi,

as a packaging contributor to the openSUSE eco system, I'm missing a changelog or a version tag at least, that relates the content of Noto-hinted.zip from http://www.google.com/get/noto/ to this repository in order to document the changes in the package.

[dougfelt]

Yes, that's a very good suggestion.

A changelog is a bit beyond us at this point, but we can at least start tagging the repos and referencing those tags.

My plan is to do the following (@jungshik would appreciate your input): 1) by default require that all source repos (noto-fonts, noto-cjk, noto-emoji) be at a commit corresponding to a 'release' tag (any attributed tag) before building the website packages. This can be overridden for testing or exceptions. We'll use a simple tag based on date followed by a short one or two-word mnemonic.

2) generate a README file in each .zip with contents based on the source repo of the files in the zip. For the 'universal' zips the contents will include information about all three repos, for the family-based zips the assumption is all files in the family come from one repo and the readme will reference only that repo.

3) The README has an intro message pointing at the get/noto site. A line would provide the date of the build. Following would be sections with information about each repo sourced. For example a README for a family from noto-fonts might be:

This package is part of the noto project.  Visit
google.com/get/noto for more information.

Built on 2017-03-08 from the following noto repository:
-----
Repo: noto-fonts
Tag: v2017-03-06-phase3-initial
Date: 2017-03-06 15:25:38 GMT
Commit: 60aa0da2ee84b11e78725b4577edc2e80b009d56

Initial phase 3.

This is the first release of noto-fonts that includes phase 3 fonts in
the hinted/unhinted subdirectories.  The new fonts are Armenian,
Cherokee, and Hebrew.

When we bypass the 'release tag' requirement those contents would differ as there is no tag, here's what the README for the 'universal' zip might look like:

This package is part of the noto project.  Visit
google.com/get/noto for more information.

Built on 2017-03-08 from the following noto repositories:
-----
Repo: noto-fonts
Branch: <not on any branch>
Commit: 60aa0da2ee84b11e78725b4577edc2e80b009d56
Subject: Merge pull request notofonts/noto-fonts#862 from dougfelt/release
-----
Repo: noto-cjk
Branch: master
Commit: 0672328ae39ee2cbc1c260186e0c545bed2a84db
Subject: forgot to update version number, fixed
-----
Repo: noto-emoji
Branch: master
Commit: 732cb454ac854efe6ce00630fee9ae5499062056
Subject: Merge pull request notofonts/noto-fonts#101 from dougfelt/emoji_html_title

Note that I'm not currently planning on any more specific information about the contents of a zip in the README-- for example it won't include font version strings, or the hashes of the latest commit for each font. Instead there is just one README section per repo which will get reused for whatever packages include fonts from that repo.

[frispete]

What you describe is exactly what I was after in the first place :wink: and yes, that's absolutely sufficient not only for the the time being, since the tag allows somebody, that tries to relate a certain font with the git repo, and therefore is able to determine the fonts history and tell if it's the latest version, etc..

The release date allows package builder to version tag the package correctly.

Thank you very much for the warm welcome of my suggestion, which underlines the professionalism and performance of this great project, which in turn is unfortunately not natural for other Google projects in the (biased) public reception at least...