Version numbers
Reported by Eric S | March 8th, 2011 @ 08:44 PM | in OpenBaskerville 0.1
I was looking through the spec for Semantic Versioning
http://semver.org/
And figured how nice it would be to have something like that for
OpenBaskerville
Version data
This is, as far as I understand this stuff.
OpenType fonts have two version fields:
fontRevision
and
openTypeNameVersion
UFO allows you to set versionMajor and
versionMinor, (as ints) from which fontRevision
will be derived.
It also allows you to set openTypeNameVersion directly as
a string.
With regards to fontRevision:
Its composed of exactly two numbers.
That means 1.2 is a valid value,
as is 3456.8902,
but 1.1.2 is not.
Secondly, Windows doesn’t accept font values with a major
version number of 0.
So 0.1 is not a valid value.
You have to start at 1.0
This is clearly bad news, as normally 1.0 in an Open Source Project signifies a stable release.
All of this leads me to doubt how useful fontRevision is for Open Source versioning
I propose for OpenBaskerville to not use fontRevision :
set it to 1.1 and forget.
We set canonical version information in
openTypeNameVersion.
Where to display version numbers
The question is: how visible should version numbers be to end users? Should they be visible in the font menu (in that case they need to be part of the font’s name)?
I say yes, even though it looks sort of weird as opposed to traditional fonts. But the most important consideration is this: if a designer sets text in a font, in most cases she or he has to know that this font is NOT going to change. If the font is called Open Baskerville 0.1.22 the designer knows she or he will always be able to redistribute this specific version of the font with the design.
Patch versions
I would like to follow semantic versioning’s distinction of X.Y.Z where X is the major version, Y is the minor version, and Z is the patch version.
We set milestones for minor versions. So now, we’re working towards OpenBaskerville 0.1
At 1.0, Open Baskerville can be considered finished.
Normally, a patch version corresponds to a conceptual unit the patch, which can consist of multiple commits. Specific commits can be referenced by their SHA hash. However, it’s possible to imagine for any given state of the development tree the font sources will be used to build a font that is going to be used in a design. Since referencing a hash is potentially confusing to the designer, I propose that we have the patch versions have a one on one relationships to commits. In essence, the patch version number will be the number of commits since the last minor version.
So that would mean, we’re at OpenBaskerville v0.0.47
This number can be easily derived in Git, by tagging the minor version and using ''git describe'' to count the number of commits since the last tag. I tagged the first commit as v0.0.0 So:
$ git describe
gives
v0.0.0-47-g3cd3c6b
For us would mean: version 0.0.47, hash g3cd3c6b
Let me know what you think,
Thanks!
best,
E
Comments and changes to this ticket
-
Eric S March 10th, 2011 @ 09:11 AM
- Milestone set to “OpenBaskerville 0.1”
-
Simon Pascal Klein March 14th, 2011 @ 04:35 PM
Great idea. I’m swamped with work and won’t have the time atm to look into SemVer closely but I think I‘m sold.
How does this impact adding new commits — do we need to
git describethem?—Pascal.
-
Eric S March 15th, 2011 @ 12:38 PM
No, we’ll only have to tag minor versions. Then the build script can derive a patch version number, and bake that into the font.
Markdown ate my line breaks (I’ve updated the ticket):
git describe yields output, the last tag, and the number of commits since that tag.
We could programmatically base our version number on that.This is just making it easy on ourselves, it is not really true to the semver spec because there they do expect you to tag every version manually…
-
Eric S March 15th, 2011 @ 12:50 PM
From the upcoming rakefile :)
# derive a version number from the current tag + number of commits (patch # version) task :_version_number => :_has_git do git_describe = `git describe`.strip # v0.0.0-49-gb5cc6c0 -> 0.0.49 (gb5cc6c0) # http://www.rubular.com/r/kqgRzxS8G9 version_number = git_describe.gsub /[v]?([0-9]+)\.([0-9]+)\.0-([0-9]+)-([\w]+)/ , '\1.\2.\3 (\4)' if version_number == git_describe abort "Unable to automatically generate patch version number" end version_number_short = version_number.split[0] puts "Generated version number #{version_number}" endMy idea is that in the source tree the font has a general version number like 0.0.x development series, based on the current minor version number. So we only have to change this every time we release a minor version (which is not all too often).
To make a patch release, we just run ''rake release'' it derives the actual version number from the git tree, bakes this into the font metadata, and generates an OTF named OpenBaskerville-0.0.49.otf or similar?
-
Simon Pascal Klein March 17th, 2011 @ 04:03 PM
I think I understand, and yea, sounds good. Will have to grab you sometime by Skype and get you to run me through it so I can update the OB web page to add the info to the workflow.
-
Eric S March 17th, 2011 @ 05:11 PM
- State changed from “new” to “resolved”
Okay, then I’ll close the ticket for now, we’ll have to see how it works out in practice :)
Reference commit: https://github.com/klepas/open-baskerville/commit/939f078870987826d...
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Open Baskerville is an open source project to create a digital revival of the famous ‘Baskerville’ typefaces. To be more exact, Open Baskerville is based upon Fry’s Baskerville, a Baskerville derivative created by Isaac Moore, a punchcutter who worked for John Baskerville. work. The font is to be licensed under either the SIL OFL or the GNU GPL v3.
Eric S
Simon Pascal Klein