Regarding Future Version Numbering

[phoepsilonix]

The revision portion of the version number in base/mozc_version.txt, created by base/BUILD.bazel, appears to be set to 2. Previously, it was 102.
It is now a lower number.

Mozc-2.32.5994.2+24.11.oss

before

Mozc-2.32.5994.102+24.11.oss

I understand that specifying --config dev_channel will make it work the same as before.
0679f6c

Going forward, it seems safe to understand that the development version revision is the default stable revision plus 100, correct?

I have a question.

1. Will the Google Mozc tags also change accordingly?
   current tag: 2.32.5994.102
   future: 2.32.5994.2 or 2.32.5994 etc
2. Will revision numbers starting with 0 be assigned when BUILD_OSS and similar files are updated in the future? d9c3f19
3. Is data/version/mozc_version_template.bzl also scheduled to be modified?(The current REVISION is 100.)
   REVISION = 0, REVISON=2, etc

If the future version numbering scheme has been decided, please let me know.

PS
I would like to confirm the positioning of dev_channel, especially in Linux. This is because version numbers also play a role in package update operations.

When the MAJOR,MINOR number or BUILD_OSS is updated, will future stable releases use a small revision number? Will the displayed Mozc version, which converts the “ばーじょん,” default to a format like Mozc-2.32.5994.2+24.11.oss?
Since the dev_channel is strictly a development version and not stable, I believe the version numbering for packages in various Linux distributions should align with the stable version.
That is why I asked the above question.
I apologize for the inconvenience during your busy schedule, but I would appreciate it if you could share the future policy.
Thank you in advance.

[hiroyuki-komatsu]

Going forward, it seems safe to understand that the development version revision is the default stable revision plus 100, correct?

Yes.

1. Will the Google Mozc tags also change accordingly?
   current tag: 2.32.5994.102
   future: 2.32.5994.2 or 2.32.5994 etc

Yes, we will probably use the "2.32.5994" style.

2. Will revision numbers starting with 0 be assigned when BUILD_OSS and similar files are updated in the future?
   d9c3f19

3. Is data/version/mozc_version_template.bzl also scheduled to be modified?(The current REVISION is 100.)
   REVISION = 0, REVISON=2, etc

I'm not certain what "revision numbers starting with 0" exactly means, but REVISION in mozc_version_template.bzl is no longer used by Bazel builds. REVISION will be probably removed once GYP builds are completely removed.

PS
I would like to confirm the positioning of dev_channel, especially in Linux. This is because version numbers also play a role in package update operations.

dev_channel may contain new / experimental / relatively-unstable features. It's controlled by the --config dev_channel flag for Bazel as you know.

When the MAJOR,MINOR number or BUILD_OSS is updated, will future stable releases use a small revision number? Will the displayed Mozc version, which converts the “ばーじょん,” default to a format like Mozc-2.32.5994.2+24.11.oss?

Technically speaking, it should be fine to use the same revision number between stable and dev, although Google Japanese Input uses a smaller revision number for stable.

Since the dev_channel is strictly a development version and not stable, I believe the version numbering for packages in various Linux distributions should align with the stable version.

It may depends on the packaging policy. If a package uses a specific tagged version, using stable channel makes sense. On the other hand, if a package always uses the head of commits, it's sounds dev channel.

We will perhaps introduce --config stable_channel too, and change the default behavior from stable to dev. So that the default versioning behavior will be reverted to the previous behavior (e.g. revision=102) while packagers have an option to use the stable channel.

Thank you for your question!

[phoepsilonix]

Thank you for your response.
If the policy is to wait for a major upgrade (version number update) before packaging, it seems better to wait for the stable_channel to be added.

1. The plan is to adopt a style where revisions are also removed from tags.
2. mozc_version_template.bzl is already deprecated. (Out of maintenance) Or does “revision only” mean it's unused?

I'm glad I was able to confirm the above as well.
Thank you for your time despite your busy schedule.

[yukawa]

The plan is to adopt a style where revisions are also removed from tags.

My understanding is yes.

mozc_version_template.bzl is already deprecated. (Out of maintenance) Or does “revision only” mean it's unused?

My understanding is that mozc_version_template.bzl itself continues to be used even after the GYP deprecation. Only revision field will be deprecated.

[yukawa]

Just fyi, the versioning scheme here mostly came from the Google Japanese Input.

• 2.32.5994.0 -> Windows stable build
• 2.32.5994.1 -> macOS stable build
• 2.32.5994.100 -> Windows dev build
• 2.32.5994.101 -> macOS dev build

The above versioning scheme is something we have been using for more than 15 years in Google Japanese Input.

The key point is that the revision number can vary depending on the target platform and target channel (stable vs dev) even built from the same source code. This is why we plan to remove the revision number from the git tags. It's not unique across platforms and channels.

[phoepsilonix]

In Linux, many distributions such as Debian, Ubuntu, and Arch have primarily adopted revision 100 or 102.
This revision number has been incorporated into the package version number as part of the versioning scheme.

I believe this became a convention.
102 is the same value as the revision in mozc_version_template.bzl plus 2. Currently, it's the same as the revision obtained with bazel --config dev_channel. Alternatively, some distributions seem to have decided to fix it at 102.
When the number changes with the next major Mozc upgrade, I hope to coordinate this for the parts I'm involved with.
Ideally, aligning the version number generated by converting the “ばーじょん” with the package version number would reduce confusion during inquiries and such.

Your detailed response was very helpful.
Thank you very much.

[hiroyuki-komatsu]

REVISION in mozc_version_template.bzl is no longer used by Bazel build. So even if that value is modified, the revision number is not changed. The --config dev_channel (or --config stable_channel in future) is the option to change the value.

REVISION will be removed once the GYP build is removed. I hope it will be less confusing.

Note, we don't provide an official way to keep using 102 for stable_channel.

Best regards,

[hiroyuki-komatsu]

I submitted c1fa943 and dab80b0.

The default channel is reverted to the dev channel, so the default revision number is also revert to "102" instead of "2". The stable channel can be selected by using the --config stable_channel flag.