Think about limiting long-term compat to CLDF variant of the dataset

[xrotwang]

@xflr6 maybe we can brainstorm interface-specification etc. here.

• how do pyglottolog and glottolog/glottolog relate to over time? Specified combinations of compatible versions?
• what about treedb?
• should all refs content be part of the CLDF?
• create CLDF releases of older Glottolog releases.

[xflr6]

Slightly reladed re: versioning metadata; should we make a version string field here (non-template) and read from here?

glottolog/config/publication.ini

Line 19 in ea763ab

title_format = glottolog/glottolog: Glottolog database {0}

[xrotwang]

@xflr6 you mean store the actual version string there? So that would act like the version in python's setup.py - you set it before making a release and then increment and append a .dev0?

[xflr6]

Yep. I guess that would mean changing glottolog-admin release <version> to glottolog-admin release in RELEASING.md.

[xrotwang]

Sounds like a good idea - also the side effect that each non-released commit would have a .dev in the version string.

[xflr6]

Cool. I started including config/*.ini in treedb so it would consume that as well.

[xrotwang]

@xflr6 The next release (4.4) will include a version option in the zenodo section, set to "x.y(.z)?" for proper releases and "*.dev0" for "dev mode". I kept title_format as it was to make backward compatibility simpler (although it feels a bit weird to plug one config option into the other "by hand", when the config format would already do interpolation).

The way I check for "proper" release is via

not pkg_resources.parse_version(version).is_prerelease

[xflr6]

Thanks Robert. Importing this as Dataset.version in treedb: 3a2bd36f6bdab41314bc782a91e8f187eb132cc1.