Page MenuHomePhabricator

Establish a regular release process for codesniffer
Open, Needs TriagePublic

Description

I suggest establishing a regular release process, both for making it easier for new contributors to understand and to document the steps that are required

Needed steps:

  • update HISTORY and README
  • tag and sign the new version
  • tell libraryupgrader to use the new version

anything else?

Discussion points:

  • How often should a new version be released?
  • Should there be a dedicated task for each new release? (eg T266476, T245309)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DannyS712 added a project: PM.
DannyS712 updated the task description. (Show Details)
DannyS712 added subscribers: Daimona, Reedy.

Also, would it be possible to have @ReleaseTaggerBot comment on the underlying bug tasks, so that it can be clear when new patches or changes when be released? Though that leads down to the rabbit hole of adding on-wiki release notes too...

Also, would it be possible to have @ReleaseTaggerBot comment on the underlying bug tasks, so that it can be clear when new patches or changes when be released? Though that leads down to the rabbit hole of adding on-wiki release notes too...

I would desperately not like for RTB's mission to expand to libraries. It's exclusively a papering-over-the-cracks-in-the-weekly-train system, and when we switch to k8s/image containers I was expecting for it to be decommissioned.

When I was the primary maintainer, I would aim to do a release roughly every month, as long as there were substantial changes. Often times we'd use PHPCS to assist with some other task, like PHPUnit or PHP version upgrades, which would necessitate a faster cycle. Or if someone has an in-progress patch, it might make sense to wait a few more days to get it included.