Version numbers

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

Reported by Eric S · March 8th, 2011 @ 08:44 PM

Activity

Eric S
- Milestone set to OpenBaskerville 0.1
March 10th, 2011 @ 09:11 AM
Simon Pascal Klein
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 describe them?

—Pascal.

March 14th, 2011 @ 04:35 PM
Eric S
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…

March 15th, 2011 @ 12:38 PM

Eric S

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}"
end

My 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?

March 15th, 2011 @ 12:50 PM

Simon Pascal Klein
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.

March 17th, 2011 @ 04:03 PM
Eric S
- 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...

March 17th, 2011 @ 05:11 PM

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.