Workflow and Versioning

Alexandru Năstase

Hello everyone,

I've just started out in type design seriously a couple of months ago and I want to improve and adapt a certain workflow when it comes to designing type.
I'm already using Git(Github/Bitbucket) but I can't seem to keep a certain workflow and a certain number of branches.

My questions are these:
1. On what premise do you give a version name to your file(1.0,1.01)?
2. Do you only stay in the Master Branch on GIT? Or do you branch out and I don't know, have something like a Branch for each master or style?
3. How do you work when you collaborate with someone else or do remote work? Do you use a UFO file?

Thank you so much everyone!

Thomas Phinney

Well, first off, there is the question of what version to start with. I'm inclined to start at 0.1 and work my way up. If you are starting at less than 1.0, be sure to leave yourself more room than you think you could possibly need with your versioning system. If you are bumping versions, each new build should have a new version. If I were starting a project today, I'd use a version string like 0.1.2002293 for my third version 0.1 build on 20/02/29. (I currently have a project that is not really using version strings. I have gotten mostly away with it, but I regret not using them.)

I can’t imagine why one would need a branch for each master or style.

What file format to use and how to collaborate depends a bit on your tools, and what part of the work you are each doing. If you are doing work on separate glyphs, then using UFO files and only checking out the specific glyphs you need might be best.

Alexandru Năstase

@Thomas Phinney thank you so much for the reply!

The version 0.1.200229 method sounds really good! I will definitely start using that from now on!
For a new version, let's say version 0.2 when you say a new build, are you referring to a new export to OTF/TTF of the file you're working on? At this point, I'm using only Glyphs App to edit and export, no other scripts.

Regarding the file format, that was spot on the case I had, working on specific glyphs remotely, thank you for the advice!

John Hudson

I date folders, but not files. File names for sources and pre-release* fonts get a build number: b001, b002, etc.

The fonts and source contain version strings, but generally I only rev those when there are changes to the glyph set or other significant functional differences. Out of habit, all my beta fonts are 'Version 0.80', and the first release version is 'Version 1.00'. Typically, I stick the build number in the version string when I generate a font, so I know from what source it was made, e.g. 'Version 0.80 b064'.

___

* Personally, I like to keep build numbers in the release font file names, but some customers want the font file name to always be the same regardless of changes or updates.

Helmut Wollmersdorfer

Git allows many ways to identify the state of work. First, each commit gets a unique ID automatically.

Release is usually an ID that's given by the author. A good way for naming releases is using numbers like 1.2.3, or better 1.02.03. which mean major.minor.maintenance. For small projects not releasing often major.minor is good enough. The term release implies giving it free for others. This allows to use the release ID in communication with others for diagnostics or whatever. Sometimes it's useful to append a tag like alpha, beta, devel, trial, nightly_build_20191031 to the release number to signal the quality level.

Usually a release has a build, i. e. one or more deliverables like myFontName-v1.02.zip or ...-v1.02.free.zip, ...-v1.02.commercial.zip etc. Github supports it, to have the deliveries in the download area of your project. A good and usual way is to tag a certain commit state of your repository by the version ID, e. g. tag=v1.02.

It depends on your toolchain, how you handle builds and releases. In software I usually begin with version 0.01, commit often in logical units with comments, push to github or my private git server. Before release I build locally testing the build process with many automatic quality checks. Then I release a TRIAL release. My toolchain forces me to use a higher release number, checks the changelog, license, builds docs, checks if everything is committed, pushes to github, releases the deliveries to the targeted software repositories. After some days or weeks of testing by third parties I build a new "official" release with a new release number.

Branches make sense if you have a larger project, many contributors, working on a production version e. g. 4.x and a new version e. g. 5.x in parallel, or working on experimental features, massive refactoring, or maybe adding e. g. cursive to a font family.

Johannes Neumeier

1. On what premise do you give a version name to your file(1.0,1.01)?

I usually bump the version when a change to the design has been made. I like semver (short for semantic versioning) from other environments applied to fonts, so major.minor.patch numbers, e.g. 1.24.2

My own reasoning is that the patch digit should be bumped on any changes, the minor when metrics or other changes will reflow documents, and major when the fonts have been reworked throughout.

2. Do you only stay in the Master Branch on GIT? Or do you branch out and I don't know, have something like a Branch for each master or style?

I use the 'master' branch only for the latest stable/released version, individual branches for charset/script extensions, e.g. branch 'arabic', and 'dev'/'production' for preparing the fonts for release, which is when the work gets merged into 'master'. This is when collaborating through a git workflow becomes interesting, because one designer can work on a specific script or part of the font, another might touch only kerning, and the dev branch contains a working combination of all those continuously being pulled in. Generally speaking, unless everybody is very git-savy you do best to have someone in charge of merging in changes to your "main" branch, and keep designers working in their respective branches.

3. How do you work when you collaborate with someone else or do remote work? Do you use a UFO file?

Mostly glyphs or UFO — both are in their own way annoying for a git workflow. glyphs contains a lot of "unnecessary meta" that causes merge conflicts you have to manually review, whereas UFO is a mess with the number of files associated with each font source, and maybe it is not your main "working" file format.

Dyana Weissman

Workflow/best practices really depends on the project, and how many other people are working on it as well.

1. I don't version my source files. I versioned them before GitHub, but now I find that can cause conflicts when syncing (especially when collaborating). With each commit I try to be precise about what's been changed, so in case I have to go back, it's actually easier to read a summary than to guess which number has the data I'd want. 

2. I stay in the Master branch when working on a project alone. I would use branches when working with others, especially if the size of the project is pretty big. I wouldn't put each style in its own branch. 

3. Yes, always UFO, but that's just what I know best. We make use of branches then. Collaborating remotely can be challenging. Then it's not as much about workflow as it is about communication and being clear with everyone's expectations. Video meetings with screenshare are important, not just for talking about the work, but also for conveying tone and emotion that is otherwise lost in text/email. A lot of people don't understand how absolutely crucial that is for a project to go well. 

Paul Hanslow

Dyana Weissman said:

3. Yes, always UFO, but that's just what I know best. 

Dayna, any issues with Git and its syncing of UFO files? I don't use UFOs all that much but wish to know if Git uploads them correctly. 

Dyana Weissman

Who's Dayna?

99% of the time I don't have problems. When I do, it is usually a bug on my computer or with RoboFont, so I can't blame git. Sometimes a collaborator will have an issue and then it can be any number of things, but I don't think it's the UFO's fault, necessarily, but honestly, at that point I get our tech support person to figure it out. 

Simon Cozens

git works just fine with UFO files. In fact, git works particularly well with UFO files, because git is file-based and with UFO each glyph is a separate file. That means you get a per-glyph version history, and you don't waste space storing lots of copies of unchanged glyphs.