You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, .keyboard_info does not include information on whether a keyboard is deprecated. That's not ideal. The deprecation is entirely by cross-reference to another keyboard. The concept is that the new keyboard is updated and references the old keyboard, which is good. The bad bit is that the old keyboard doesn't know that it is deprecated, so downloads.keyman.com has no data on it. api.keyman.com/keyboard adds the deprecation back-reference to the deprecated keyboard when it builds the database.
There is a convention of adding DEPRECATED.md to a keyboard source folder, which does not entail publishing an updated version of the keyboard. But it is informative for keyboard authors, and is not currently used during the build.
A wrinkle: a deprecation relationship may reference a keyboard that is not in the keyboards repository. This is particularly true for older keyboards.
Idea
We check DEPRECATED.md existence during keyboard build, and use that to mark a keyboard as deprecated. We could also cross-reference that when we find a keyboard relationship -- but this is hard because we don't reference the full path (e.g. legacy/a/anii_2015_fr_pack2) but only the package name (e.g. anii_2015_fr_pack2), so that is expensive.
We would have to consider whether we need to add an extra field to the .keyboard_info (as we don't necessarily have a deprecatedBy keyboard to reference). Perhaps call it a status field: { stable, experimental, deprecated, legacy, test } (test would be similar to experimental but primarily for internal use, see #2865 for example).
#2865 (comment)
Right now, .keyboard_info does not include information on whether a keyboard is deprecated. That's not ideal. The deprecation is entirely by cross-reference to another keyboard. The concept is that the new keyboard is updated and references the old keyboard, which is good. The bad bit is that the old keyboard doesn't know that it is deprecated, so downloads.keyman.com has no data on it. api.keyman.com/keyboard adds the deprecation back-reference to the deprecated keyboard when it builds the database.
There is a convention of adding DEPRECATED.md to a keyboard source folder, which does not entail publishing an updated version of the keyboard. But it is informative for keyboard authors, and is not currently used during the build.
A wrinkle: a deprecation relationship may reference a keyboard that is not in the keyboards repository. This is particularly true for older keyboards.
Idea
We check DEPRECATED.md existence during keyboard build, and use that to mark a keyboard as deprecated. We could also cross-reference that when we find a keyboard relationship -- but this is hard because we don't reference the full path (e.g.
legacy/a/anii_2015_fr_pack2
) but only the package name (e.g.anii_2015_fr_pack2
), so that is expensive.We would have to consider whether we need to add an extra field to the .keyboard_info (as we don't necessarily have a deprecatedBy keyboard to reference). Perhaps call it a status field: { stable, experimental, deprecated, legacy, test } (test would be similar to experimental but primarily for internal use, see #2865 for example).
Example: anii deprecates anii_2015_fr_pack2
keyboards/release/a/anii/source/anii.kps
Lines 138 to 140 in 6c98e2f
This is published to the API site and downloads site, for anii.
https://api.keyman.com/keyboard/anii:
https://downloads.keyman.com/keyboards/anii/1.0/anii.keyboard_info:
And api.keyman.com shows the deprecatedBy relationship for anii_2015_fr_pack2:
The text was updated successfully, but these errors were encountered: