conventional-changelog-archived-repos / conventional-recommended-bump Goto Github PK

$ conventional-recommended-bump

Produces just an empty output.

Great work stevemao,

I have one question: when I run conventional-recommended-bump --verbose -p angular the output is the same as conventional-recommended-bump -p angular. I would expect further info about the reason a certain bump has been chosen.
Looking at the source code, I can't see any debug message.

Leonardo

As per the docs;

var conventionalRecommendedBump = require('conventional-recommended-bump');

conventionalRecommendedBump({
  preset: 'angular'
}, function(err, releaseAs) {
  console.log(releaseAs);
  //=> 'major'
});

Since a recent update what is more accurate is

var conventionalRecommendedBump = require('conventional-recommended-bump');

conventionalRecommendedBump({
  preset: 'angular'
}, function(err, releaseAsObj) {
  console.log(releaseAsObj.releaseAs); // Its now an object.
  //=> 'major'
});

I don't know whether the code or the documentation should be updated, otherwise I would create a PR

conventional-changelog-archived-repos/conventional-changelog-angular@7dce559

feat(noteKeywords): make BREAKING CHANGE more forgiving

People might type BREAKING CHANGES unintentionally. EG: https://github.com/angular/angular/commit/098b461

This repository has been archived (as I just realized), since the package was merged into the conventional-changelog monorepo - https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-recommended-bump

Could the issues, and pull requests, please be closed out to reflect the move?

use a config file

Correct me if I'm wrong, but it seems that the conventional-recommended-bump → git-latest-semver-tag → git-semver-tags calls review the complete git log history just to determine the latest tag (so it knows how far back to go when determining the recommended version bump). This is definitely robust, but it seems a little inefficient/unnecessary for a tool like standard-version that already knows which version (and thus, which tag) it wants to start from.

If we allowed a starting version to be specified, then perhaps conventional-recommended-bump could first verify a git tag exists for that version and, if so, use that as the starting point instead of jumping through the git-latest-semver-tag → git-semver-tags hoop. If no git tag is found for the given version, it could either return an error or fallback to the existing functionality.

What do you think? Is there something I'm missing about how this works?

I just did an npm publish and ./node_modules/.bin/conventional-recommended-bump --preset=angular returns patch although there aren't any new commits since last publish. Is that the expected behaviour? Shouldn't just the command fail since there is not need to bump to a new version?

I am getting following error while running conventional-recommended-bump as suggested in docs.

events.js:74
        throw TypeError('Uncaught, unspecified "error" event.');
              ^
TypeError: Uncaught, unspecified "error" event.
    at TypeError (<anonymous>)
    at Readable.emit (events.js:74:15)
    at DestroyableTransform._transform (C:\Users\dshuk4\AppData\Roaming\npm\node_modules\conventional-recommended-bump\node_modules\git-raw-commits\index.js:48:16)
    at DestroyableTransform.Transform._read (C:\Users\dshuk4\AppData\Roaming\npm\node_modules\conventional-recommended-bump\node_modules\git-raw-commits\node_modules\through2\node_modules\readable-stream\lib\_stream_transform.js:172:10)
    at DestroyableTransform.Transform._write (C:\Users\dshuk4\AppData\Roaming\npm\node_modules\conventional-recommended-bump\node_modules\git-raw-commits\node_modules\through2\node_modules\readable-stream\lib\_stream_transform.js:160:12)
    at doWrite (C:\Users\dshuk4\AppData\Roaming\npm\node_modules\conventional-recommended-bump\node_modules\git-raw-commits\node_modules\through2\node_modules\readable-stream\lib\_stream_writable.js:323:12)
    at writeOrBuffer (C:\Users\dshuk4\AppData\Roaming\npm\node_modules\conventional-recommended-bump\node_modules\git-raw-commits\node_modules\through2\node_modules\readable-stream\lib\_stream_writable.js:309:5)
    at DestroyableTransform.Writable.write (C:\Users\dshuk4\AppData\Roaming\npm\node_modules\conventional-recommended-bump\node_modules\git-raw-commits\node_modules\through2\node_modules\readable-stream\lib\_stream_writable.js:236:11)
    at Socket.ondata (stream.js:51:26)
    at Socket.emit (events.js:117:20)

How does a commit need look to trigger resp. a minor, major or patch change? I saw something with BREAKING CHANGE:

Latest version 0.3.0 should have been 1.0.0

According to SEMVER

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

This impacted our ability to ship code for a day while investigating our broken CI which allowed installing minor version of conventional-recommended-bump.

When semantic-version submits a pull request that bumps a dependency version, it's usually the case that you want to release a new point-release with the dependency update. Should chore along with fix result in a patch bump?

The docs say that you get a string "major", "minor", "patch"; in reality you get an object that contains a releaseAs property that contains these values.