leviy / release-tool Goto Github PK

Depends on #5, #13

Sometimes the changelog contains changes that should be left out of the changelog. For instance, pull requests merging the changes of a release branch back into master.

We should cryptographically sign the distributed release-tool.phar so people can validate it. Also, we should check the signature in the self-update command (#44).

This allows to list releases on GitHub Releases, which supports release notes, downloads, etc.

• Find a way to securely store the GitHub API credentials - probably in a file in the user's home directory. See for instance how Composer does this (~/.composer/auth.json)
• Create a new release using the GitHub API
  • Use the version number (without the VCS tag prefix) as the release name

Release notes, prereleases and release assets are out of scope for now and will be added as part of future issues.

Requires #6

Requires #4 to configure the repository name to create the release in - unless we can think of a smarter way to automatically determine this?

• Choose a license
  • Create a LICENSE.txt file containing the license information
  • Specify the license in composer.json
  • Add a license badge to the README
• Find out if we need contributors to agree with our license in some way
• Make this repository public
• Publish as a Composer package

When a new version of a project is released, its changelog doesn't list changes that have been introduced earlier as part of a pre-release version.

It would be nice if the changelog of a new full version would also include the changelogs of its pre-release versions, so people don't have to look those up separately to see all that's been changed.

When I choose to release a manually chosen version (Let's say 0.0.5, so ./release-tool.phar release 0.0.5), the tag gets properly prefixed with the configured prefix (v0.0.5) but after pushing the tag to the repository, the releases-page (github) says the name of the release is 0.0.5 instead of the v0.0.5 as would be done when using the yes/no questions-path.

TLDR
Manually supply tag
Release > Tag is prefixed > Release name on GitHub is not prefixed.
Calculate the tag
Release > Tag is prefixed > Release name on GitHub is prefixed.

At the very least, this should allow users to configure the "release steps" that should be executed when releasing a new version.

The release tool should look for a file in the current working directory (something like .release-tool.yml) and read the contents to apply the configuration.

Example .release-tool.yml, with default values:

versioning-scheme: semantic

vcs:
  git:
    tag-prefix: v
    remote: origin

post-release-actions:
  github-release: ~

The configured values should be used when compiling the service container.

See https://github.com/Behat/Behat, https://github.com/sensiolabs-de/deptrac for examples.

• design a good and scalable configuration format
• use symfony/yaml to read the file

Probably requires #7

Prereleases are releases that are not considered production-ready. The tool should support prereleases as special releases:

• GitHub releases (#5) should be marked as prereleases
• Interactively calculated version numbers (#9) should have a prerelease label (-beta, -alpha, etc. in case of semver)
• Releasing a non-pre-release version when the previous release is a pre-release should not increment the major/minor/patch versions. I.e. when the previous release is 1.1.0-beta.1 the next (non pre-release) version should be 1.1.0.

Right now objects are instantiated in bin/release, which does not scale well.

Find a way to use the dependency injection container in a console application.

• Find a way to use the service container in a command line application
• Create a config directory containing services.yaml files
• Inject the right services in the commands and add the commands to the application

Create a release note generator that can generate release notes based on the VCS history since the previous release.

See for example https://github.com/leviy/rmt-changelog-formatter

• Create a release note generator interface so that we can have multiple implementations
• Create an implementation that generates release notes based on GitHub pull requests

Issue numbers in pull request titles should be converted into links, linking to the issue tracker URL for that issue.

This should support:

• JIRA issue numbers (ABC-123) where "ABC" should be a configurable prefix
• GitHub issue numbers (#123) - make sure that this differentiates issue numbers from pull request numbers

Perhaps the user should be able to configure a regular expression for detecting issue numbers.

Requires #4

Consider using https://github.com/humbug/phar-updater

Currently the first release can be specified manually (release-tool release 1.0.0), but trying to automatically calculate the first version number will result in an error because there are no existing Git tags.

It should be possible to release a first version (release-tool release), resulting in a version 1.0.0.

It should also be possible to start with a pre-release version (release-tool release --pre-release) which should result in 1.0.0-alpha.1, 1.0.0-beta.1 or 1.0.0-rc.1 depending on interactive questions.

Major version 0 (0.y.z) is not taken into account here: users who want to start with a 0.y.z version should provide the version number manually.

• Make the version argument for the release command optional
• If the version argument is missing, ask interactive questions based on a versioning strategy
• Create a semantic versioning strategy
• Determine the current/last version based on the current branch - meaning, that if another branch contains a 2.0.0 version but the latest version on the current branch is 1.3.0, a new (minor) version will be 1.4.0, not 2.1.0.

Currently the compiled PHAR is quite big: 18.5 MB. For reference: Composer is around 1.8 MB. Removing development dependencies should reduce the size to around 2.2 MB, which is a huge improvement.

See https://github.com/leviy/release-tool/pull/35/files/e6fe1a69beada77909a0d4816e5fec4ed8637a33#r199961790

Ask for user confirmation before pushing anything to a remote repository.

Providing a phar download is required to use the Release Tool in projects that are not PHP/Composer projects or that have conflicting (Symfony) dependencies. The downloaded phar can be installed globally by placing it in a directory that is in the user's PATH, similary to Composer.

Downloading the phar should be recommended in the README over adding the release tool as a development dependency for the above reasons.

Build the phars in Travis CI and upload them (using Travis CI Deployments) to the GitHub Release (#5).

• Add a target to the Makefile that creates a phar archive
• Set up Travis CI to automatically build the phar when a tag is pushed, and upload the phar to the GitHub release.
  • The file name of the uploaded phar should be static (not containing the version number, i.e. release-tool.phar) so the latest release can be automatically downloaded by a script.
• Add installation instructions using the phar to the README, both for a project-local installation as well as a global installation. Point out that the phar installation is recommended instead of installing as a Composer dev-dependency.

PHP Fatal error:  Uncaught Leviy\ReleaseTool\Vcs\GitException: fatal: not a git repository (or any of the parent directories): .git in phar:///home/nic/.local/bin/release-tool/src/Vcs/Git.php:48
Stack trace:
#0 phar:///home/nic/.local/bin/release-tool/bin/release(44): Leviy\ReleaseTool\Vcs\Git::execute('git remote get-...')
#1 /home/nic/.local/bin/release-tool(14): require('phar:///home/ni...')
#2 {main}
  thrown in phar:///home/nic/.local/bin/release-tool/src/Vcs/Git.php on line 48

See https://evertpot.com/testing-composer-prefer-lowest/

This will automatically verify that our version constraints in composer.json are up-to-date. It might also allow us to configure looser version requirements, for instance for the symfony packages, so this tool can be used as a Composer dependency in older projects (that use Symfony 2/3 packages).

Depends on #13 - also on #4 to determine the Slack workspace / channel to post to

Store Slack credentials in a way similar to #5

Depends on #4, #5

• Upload assets using the GitHub API
• Allow specifying multiple files to upload
• Allow uploading files that match a (glob) pattern

Discuss:
Should file paths be relative to the current working directory, or to the YAML configuration file (#4)?