module version metadata should contain release timestamp

[jkanywhere]

Tell us more.

I use renovate to maintain in my MODULE.bazel

My renovate config contains "minimumReleaseAge": "7 days",

It appears that renovate cannot determine when modules are released to Bazel Central Registry:

I get the following in logs

DEBUG: Marking 4 release(s) as pending, as they do not have a releaseTimestamp and we're running with minimumReleaseAgeBehaviour=timestamp-required (repository=spirl/spirl)
       "depName": "aspect_bazel_lib",
       "versions": ["2.22.5", "2.22.4", "2.22.2", "2.22.0"],
       "check": "minimumReleaseAge"

DEBUG: Marking 1 release(s) as pending, as they do not have a releaseTimestamp and we're running with minimumReleaseAgeBehaviour=timestamp-required (repository=spirl/spirl)
       "depName": "gazelle",
       "versions": ["0.48.0"],
       "check": "minimumReleaseAge"

DEBUG: Marking 1 release(s) as pending, as they do not have a releaseTimestamp and we're running with minimumReleaseAgeBehaviour=timestamp-required (repository=spirl/spirl)
       "depName": "bazel_skylib",
       "versions": ["1.9.0"],
       "check": "minimumReleaseAge"

More details from the logs:

               {
                 "datasource": "bazel",
                 "depType": "bazel_dep",
                 "depName": "aspect_bazel_lib",
                 "currentValue": "2.21.2",
                 "updates": [
                   {
                     "bucket": "non-major",
                     "newVersion": "2.22.5",
                     "newValue": "2.22.5",
                     "newMajor": 2,
                     "newMinor": 22,
                     "newPatch": 5,
                     "updateType": "minor",
                     "isBreaking": false,
                     "pendingChecks": true,
                     "branchName": "renovate/aspect_bazel_lib-2.x"
                   }
                 ],
                 "packageName": "aspect_bazel_lib",
                 "versioning": "bazel-module",
                 "warnings": [],
                 "registryUrl": "https://raw.githubusercontent.com/bazelbuild/bazel-central-registry/main",
                 "homepage": "https://docs.aspect.build/rules/aspect_bazel_lib",
                 "currentVersion": "2.21.2",
                 "isSingleVersion": true,
                 "fixedVersion": "2.21.2"
               },

               {
                 "datasource": "bazel",
                 "depType": "bazel_dep",
                 "depName": "gazelle",
                 "currentValue": "0.47.0",
                 "updates": [
                   {
                     "bucket": "non-major",
                     "newVersion": "0.48.0",
                     "newValue": "0.48.0",
                     "newMajor": 0,
                     "newMinor": 48,
                     "newPatch": 0,
                     "updateType": "minor",
                     "isBreaking": false,
                     "pendingChecks": true,
                     "branchName": "renovate/gazelle"
                   }
                 ],
                 "packageName": "gazelle",
                 "versioning": "bazel-module",
                 "warnings": [],
                 "sourceUrl": "https://github.com/bazel-contrib/bazel-gazelle",
                 "registryUrl": "https://raw.githubusercontent.com/bazelbuild/bazel-central-registry/main",
                 "currentVersion": "0.47.0",
                 "isSingleVersion": true,
                 "fixedVersion": "0.47.0"
               },

               {
                 "datasource": "bazel",
                 "depType": "bazel_dep",
                 "depName": "bazel_skylib",
                 "currentValue": "1.8.2",
                 "updates": [
                   {
                     "bucket": "non-major",
                     "newVersion": "1.9.0",
                     "newValue": "1.9.0",
                     "newMajor": 1,
                     "newMinor": 9,
                     "newPatch": 0,
                     "updateType": "minor",
                     "isBreaking": false,
                     "pendingChecks": true,
                     "branchName": "renovate/bazel_skylib-1.x"
                   }
                 ],
                 "packageName": "bazel_skylib",
                 "versioning": "bazel-module",
                 "warnings": [],
                 "sourceUrl": "https://github.com/bazelbuild/bazel-skylib",
                 "registryUrl": "https://raw.githubusercontent.com/bazelbuild/bazel-central-registry/main",
                 "currentVersion": "1.8.2",
                 "isSingleVersion": true,
                 "fixedVersion": "1.8.2"
               },

Currently, for each component there is a published date available by checking the commit timestamp on github:

aspect_bazel_lib: https://registry.bazel.build/modules/aspect_bazel_lib 2.22.5 "published 3 months ago" -> a92a650

On registry.bazel.build it only shows "days ago", but clicking on the link navigates to a specific commit with a full timestamp
gazelle: https://registry.bazel.build/modules/gazelle version 0.48.0 -> 87560db

bazel_skylib https://registry.bazel.build/modules/bazel_skylib 1.9.0 "published 3 months ago" -> e42de35

I started by reporting the situation to renovate by creating renovatebot/renovate#42258.
The renovate team suggests that releaseTimestamp (or equivalent) be added to the source.json for each module version, for example https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/aspect_bazel_lib/2.22.5/source.json.

[jkanywhere]

I am unfamiliar with bazel-central-registry and related tech.
AI tools suggest that timestamp could be added

• when the source.json is created, in tools/registry.py line 429
• or source.json could be modified in publish-to-bcr workflow push-to-fork

[fmeum]

@kormide

[kormide]

It would be easy to add a "release_timestamp" field to source.json if it just references the timestamp of the commit that the release tag points to. Any concerns about this @meteorcloudy? Can arbitrary fields be added or do they need to be validated on the BCR/bazel side?

[jwnimmer-tri]

It is not clear to me whether the original requestor (and/or the renovate crew) was asking for a timestamp of the upstream tag release (i.e., of https://github.com/bazelbuild/bazel-skylib/releases/tag/1.9.0), or the BCR release (i.e., when #6855 landed on BCR main).

Especially for .bcr.N fixes to the build logic, those two dates might be vastly different. For example with #4364 they differed by more than three years.

One common use case of "min age" is supply chain integrity, and in that case, I imagine the BCR age is probably what's wanted?

[jkanywhere]

I imagine the BCR age is probably what's wanted?

I agree. Time the artifact because available through the central registry makes sense to me, even when it differs from upstream release time. (But I think I would be OK either way.)

For tools that use both bazel modules and go packages, I want MODULE.bazel and go.mod updated at the same time, and for the versions to remain in sync.

[Wyverald]

It would be easy to add a "release_timestamp" field to source.json if it just references the timestamp of the commit that the release tag points to. Any concerns about this @meteorcloudy? Can arbitrary fields be added or do they need to be validated on the BCR/bazel side?

Arbitrary fields can be added, but we can't guarantee the availability of such fields. For example, publish-to-bcr can set these fields from now on, but it's not going to be retroactively added to all previous versions, nor provided by people who manually create PRs to BCR. It's certainly possible to somehow automate this (right before PR submission, have a Github Action add that field), but this seems very low priority.

[jkanywhere]

I think my earlier report was inaccurate.

Re-reading this comment from renovate maintainer jamietanna I now understand that the metadata.json, e.g. https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/aspect_bazel_lib/metadata.json, file should contain the releaseTimestamp of each version

metadata.json is fetched from here https://github.com/renovatebot/renovate/blob/467b5d2d9ced575c0a08d789e8c965df3d1af4b1/lib/modules/datasource/bazel/index.ts#L17

[meteorcloudy]

What exactly does releaseTimestamp mean? The time the release artifact is created or the time the BCR is created? I think both can be deduced without adding this field?

[jwnimmer-tri]

The time the release artifact is created or the time the BCR is created?

I asked the same upthread (see here) and the reply was ideally the timestamp of the BCR merge into master (see here).

I think both can be deduced without adding this field?

Yes. The comment from the Renovate crew was that pulling the information from the git metadata was too expensive (see here and here). Instead, they requested that BCR collate this information and publish in a more summarized form than just the git metadata.

[meteorcloudy]

Hmm, I'm not a bit fan of pushing this burden to module maintainers and BCR.

[jkanywhere]

Hmm, I'm not a bit fan of pushing this burden to module maintainers and BCR.

Please clarify, how is the time more complicated than the metadata BCR already maintains?, including:

• maintainer info: name, github account, email
• integrity check sums
• lists of existing and yanked versions
• source URLs.

The details about your concerns can help us reason about the cost and how to reduce burden.

It appears to me, as an uninformed user, that BCR's main role is maintaining metadata about many packages, and that BCR already provides various automation to make that easy for module maintainers to publish, i.e release modules.

Renovate automates the consumer side, there are other tools that do the same thing e.g. Dependabot.

The problem is that currently renovate cannot automatically upgrade BCR modules after N days because it cannot tell when the module was published. From my point of view as the end-user the functionality is equivalent if updates are done in BCR vs renovate.

It seems overall work is reduced (e.g. fewer API calls and load on BCR) by doing more in the maintainer release flow compared to the consumer upgrade flow because creating new versions of modules happens much less often than consuming those modules and checking what versions exist.

We have to agree on the key, the format for the timestamp, and where it should go in metadata.json. I can see that an extra data structure should likely be added to the metadata schema.
https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/gazelle/metadata.json

Version list and yanked are currently maintained separately.
Adding map version -> releaseTimestamp would mirror how yanked is maintained.

{
"version_release_timestamps":{
  "0.48.0": "2026-03-26 07:29:38+00:00",
  "0.26.0": "2022-07-11 10:00:03+00:00",
  "0.27.0": "2022-10-14 21:49:01+00:00",
  "0.28.0": "2022-10-26 23:18:14+00:00"
}
}

We cannot remove the existing structures, but we could "future proof" we could add a general map of version string -> object, that way if more data is added about each version we don't have to keep adding structures. (cannot remove old structures.)

Consider:

{
    "version_metadata": {
        "0.48.0": {
            "release_timestamp": "2026-03-26 07:29:38+00:00"
        },
        "0.26.0": {
            "release_timestamp": "2022-07-11 10:00:03+00:00",
            "yanked_reason": "Obsolete experimental version that emits debug prints. Update to 0.30.0 or higher"
        },
        "0.27.0": {
            "release_timestamp": "2022-10-14 21:49:01+00:00",
            "yanked_reason": "Obsolete experimental version that emits debug prints. Update to 0.30.0 or higher"
        },
        "0.28.0": {
            "release_timestamp": "2022-10-26 23:18:14+00:00",
            "yanked_reason": "Obsolete experimental version that emits debug prints. Update to 0.30.0 or higher"
        }
    }
}

I'm happy to contribute some code if someone will please point me where in BCR you would like the changes.