version numbers for core translations?

i've discovered another slightly tricky issue with the new release system and version numbering schemes for contrib: what should we do about version numbers for core translation releases?

all the core translations are in contrib, and have their own project nodes. we certainly need to allow them to make official releases, just like any other contribs. however, they have slightly different needs and properties than modules, and those could be reflected in their version strings:

• they actually care about the exact version of drupal core. in theory, it shouldn't matter, but in practice, translatable strings can and do change in the middle of a stable release series of core. so, a translation that was 100% for 4.7.3 will in fact be 98% or something for 4.7.4, unless the maintainer updates their translation. we'd like to associate translation releases (and their % status) with a specific version of core, not just the end of a given branch of core.
• they have no need for more than 1 branch for each version of core. modules might want stable vs. development branches of code that's all compatibile with 4.7.x of core, but that makes no sense for translations -- they're not code. ;) no such thing as a "new feature" -- either you translate the strings or you don't.

the way version numbers will work for the rest of contrib will be like this:

[CoreCompatibility]-Major.PatchLevel[-ExtraStuff]

the [CoreCompatibility] part is required, and will be something like "4.7.x", or "5.x". Major is the major revision number, i.e. what branch of the code this release is coming from. the default stable branch for a given release of core (DRUPAL-4-7) will be the 0 major version. additional branches will be 1, 2, ..., and will be for whatever the maintainer of the project sees fit. by convention, the even #s would be the stable series, and the odd ones would be for new feature development. the PatchLevel is for a specific release along the specified branch.
the [-ExtraStuff] is optional, for specifiying things like "-beta1" (first beta release) or "-dev" (a development snapshot from the end of a CVS branch, as opposed to an official release from a CVS tag).

so, for example, a few possible version strings for some module in contrib:

• 4.7.x-0.3 (3rd patch-level release from the default, stable branch compatible with 4.7.x versions of core)
• 4.7.x-1.0 (initial release from another branch compatible with 4.7.x versions of core, for exaple, a new-feature development branch)
• 5.x-0.0-dev (nighly development snapshots from the branch compatibile with core 5.x)

so, what should we do for translations? a few options:

1. use exactly the same scheme as modules. by far the easiest to implement (since it's already done). ;) all the CVS branch/tag conventions can be the same, so there's no special case. also, since for the most part, translations *are* pretty much the same across any given stable series of core, the "4.7.x" variablility (as opposed to a specific "4.7.3") could be considered a feature, not a bug.
2. use something like "4.7.3-PatchLevel" for official releases of translations (e.g. "4.7.3-0", "5.0-2", etc) and just use "4.7.x-dev" for snapshot "releases" from the end of the DRUPAL-4-7 branch. probably less confusing for translation users, but a lot more work for the new release system. would require different CVS tagging for translation releases.
3. some other option i haven't thought of... ;)

any bright ideas? anyone who maintains or uses translations care about this enough to a) help write the code or b) sponsor my time, to do the more fancy translation-specific option #2? we can (and probably will, given the contraints on my time) start with option #1, and just see how bad it is for translations. i'm guessing most translations will never even bother making official releases from tags, and will probably just use the "4.7.x-0.0-dev" release (re-built from the end of the DRUPAL-4-7 branch, just like the existing "4.7.0" releases are today) and not worry about it.

just wanted to give the people who maintain translations a heads-up about this issue, and solicit input. if there's a simple solution that's easy to implement, i'd be willing to get it in before the whole system goes live.

thanks,
-derek

p.s. the very first iteration of the new release system will not update the translation status pages. see http://drupal.org/node/88056#comment-144641 for more info. there will be a solution in place in the near future, do not dispair. ;)