Optimizing Release Workflows: The Quest for Silent GitHub Releases and Better Developer Performance Metrics

Managing software releases effectively is crucial for any development team, directly influencing software developer performance metrics and overall project transparency. However, a recent GitHub Community discussion highlighted a significant friction point: the inability to create historical releases silently and with accurate past timestamps.

The Challenge: Retroactive Releases Without Notification Overload

The discussion, initiated by sbc100 from the Emscripten project, detailed a common scenario: transitioning from simple Git tags to formal GitHub Releases. With approximately 200 historical tags, the goal was to retroactively create GitHub Releases for each without inundating repository subscribers with hundreds of notification emails. A secondary, but equally important, request was the ability to set the release date to match the original tag's historical commit date.

GitHub's Current Limitations and Community Workarounds

The initial response from GitHub Actions acknowledged the feedback. However, community members quickly clarified the existing constraints:

• No Native Silence: Both the REST and GraphQL APIs currently lack a parameter to suppress notifications when creating or publishing a release.
• No Backdating: The API does not allow setting created_at or published_at timestamps for releases; they always default to the current time. While the underlying Git tag preserves its original date, the GitHub Release object does not.

Several workarounds were proposed, though most came with significant caveats:

• Draft Releases: Initially suggested as a way to avoid notifications, it was quickly pointed out that publishing a draft release (whether via UI or API) still triggers notifications. Creating a release with draft: false also sends notifications, even if release notes are omitted.
• API Throttling: A practical, albeit imperfect, suggestion involved scripting the release creation with delays to spread out the notification blast. For example:

  import time, requests
  
  for tag in tags:
      requests.post(url, json={"tag_name": tag, "name": tag}, headers=headers)
      time.sleep(5) # 5s between releases
  

  This approach lessens the immediate impact but doesn't eliminate the notifications.

• Alternative Documentation: For projects where historical accuracy is paramount but GitHub's notification system is a barrier, maintaining a comprehensive CHANGELOG.md or a dedicated website that links directly to Git tags was suggested as a way to bypass GitHub's release UI entirely for historical data.
• Community Transparency: If proceeding with notifications, informing users via a pinned issue or README update about the upcoming influx of historical release notifications was recommended to manage expectations.

The Outcome and the Persistent Need

Ultimately, sbc100 decided to keep historical releases as plain tags and only create formal GitHub Releases for new versions (6.0.0 and above), acknowledging the current limitations. However, the discussion ended with a strong plea for a --silent flag, noting an inconsistency: GitHub's own project import tool reportedly does not send out emails on release creation, suggesting that the technical capability exists.

This community insight underscores a clear need for more granular control over release notifications and timestamping. Such a feature would significantly enhance developer productivity and streamline release management, providing more accurate software engineering analytics and improving overall software developer performance metrics by reducing unnecessary administrative overhead and notification fatigue. It would also facilitate smoother migrations and better historical data representation on GitHub.