emlynwest / changelog Goto Github PK

I know you said you don't really want it as it is hard to use in CLI scripts (without proper factory/DI mechanism), but for those, who write their own scripts, you could provide it. ;)

Allow logs to be pulled from github then committed.

I would like to be able to merge two or more files directly from the command line.

What do you think about such a feature ? Would you merge a PR ?

Be able to write out a log using a "reverse" parser. Providers should be updated too to allow content to be written back out.

Possibly parsers and providers should be renamed to something more descriptive for their changed uses.

Make sure the yanked flag is set if needed.

Other half of #17.

Split off due to potential complications arising to make sure data is synced somehow to try and avoid overriding changes, either remote or local.

Allow the main class to automatically construct needed classes to make it simpler to use.

Read dates in from the release titles.

It would be useful to have an adapter that uses the GitHub API.

The changelog would be generated by fetching all the releases, e.g. here https://github.com/stevewest/changelog/releases

Could be used for example here: CouscousPHP/Couscous#84

Deal with release links

Make sure that "unreleased" releases stay at the top of the release list after sorting.

Due to a oversight in the unit tests it is not possible to parse releases if they have a white space between the end of the release content and the next release's title.

# Log title

## 0.2.0 - 2015-02-26
### Changed
 - Thing 1
 - Thing 2

### Added
 - Some content

## 0.1.0 - 2015-02-26
### Added
- Initial release

Allow logs to be output as

• json
• xml

Create a set of default robo tasks for being able to work with change logs.

Add an adaptor for flysystem to read/write files

Have the ability to merge change logs into a single log.

Include a cli script to allow change logs to be manipulated via the command line.

Potential tasks:

• Convert between formats
• Make a major/minor/patch release (this would change "unreleased" to the next version number)
• Add a change to a release

Other:

• Load config file from working directory or specified at runtime for IO configs

Allow logs to be loaded from a remote URL

This constraint forbids using stable versions of the package and so makes it a pain for people using it as composer only allows stable versions by default (see composer/composer#5211)

Thus, depending on dev-master is equivalent to depending on +Inf as version of the package. It is an unbound constraint. This means that your code would break if the naneau/semver package releses a new major version (so not BC) as you will always use whatever new major version comes out for existing releases of your package.

Make sure the readme contains instructions on how to build the phar archive for release.

• Include command ./vendor/bin/robo create:phar.
• Outline process that the task takes.

Make sure releases can be ordered correctly, possibly using https://github.com/naneau/semver