RF3 updates

[horasio]

Cool, thank you! I'd like to find a way to explain that the current 'master' is the last release compatible with RoboFont pre-3. Maybe a label on the current master branch, with a explanation in the README ? What would you suggest? Is RF < 3 totally abandoned ? should we created a separate branch for RF3 ? Ideally, the repo should work with both RF<3 and RF3. Is that possible?

[gferreira]

it’s possible to make extensions work in both versions of RF simultaneously by checking mojo.roboFont.version, and using conditional statements to handle each API or syntax difference. the first extensions were updated this way. it works, but the code gets super messy – it felt against the ‘starting fresh’ spirit of RF3.

so, more recently, we’ve switched to ‘freezing’ the last RF1-compatible version using a tagged release (0.7.2 in this case), and updating de code to RF3 only. this allows us to drop legacy code and start fresh using RF3 syntax and API.

both approaches are valid, it’s up to the extension developer to decide. as a developer I prefer the second approach now, for the reasons mentioned above.

[horasio]

Is it possible to tell "Mechanic", in the info.plist, which commit/tag to use depending on the version of RoboFont ? So that the same git repo serves both RF2 and RF3.

[gferreira]

as far as I know, choosing a commit/tag in not supported in either version of Mechanic.

for my own extensions, this is the path I’ve chosen:

• RF1 users can download tagged release and install manually
• RF3 users can install and get updates with Mechanic2

[gferreira]

you could also keep the current repository for RF1/Mechanic, and start a new one for the RF3/Mechanic2 version…

[gferreira]

thanks for the questions, btw. documenting the options and their advantages/disadvantages will help other developers too. here’s an attempt to make a summary:

Paths for developers upgrading extensions from RF1 to RF3

option Ⓐ: 1 version / 1 repository

• RF1 → install via Mechanic1
• RF3 → install via Mechanic2

advantages:

• one single source code, no duplication

disadvantages:

• spaghetti code (version checking, conditionals)
• backwards-oriented, burden for future development

option Ⓑ: 2 versions / 1 repository

• RF1 → tagged release (download and install manually)
• RF3 → install via Mechanic2

advantages:

• clean RF3/py3 code, forward-oriented
• no more maintance work for RF1 (end-of-line)

disadvantages:

• breaks Mechanic1 support for RF1 users, requires manual installation

option Ⓒ: 2 versions / 2 repositories

RF1 → install via Mechanic1 RF3 → install via Mechanic2

advantages:

• available via Mechanic1 for RF1 users AND Mechanic2 for RF3 users
• clean separation between legacy RF1/py2 code and fresh RF3/py3 code

disadvantages:

• 2 versions to maintain, 2× the amount of work

• delays RF3 upgrade (?)

• • -

cc @typemytype