Auto: Custom bump commit message

I might prefer no bump commits (like semantic-release does it):

{
  "skipBumpCommit": true
}

With bump commits disabled, the latest NPM version is the source of truth (or maybe it already works that way?) and the "version" field in package.json can be set to 0.0.0-development or similar.

is skip CI different on travis? without that in your commit messages you can easily fall into a loop

auto will use look at the local version and the published version and choose the higher one to avoid npm errors. Is that sufficient?

is skip CI different on travis? without that in your commit messages you can easily fall into a loop

I'm not actually sure. If it's required in the commit header, then so be it. 😆

auto will use look at the local version and the published version and choose the higher one to avoid npm errors. Is that sufficient?

Oh really? Nice. Is no bump commit created in that case?

No in that case we bump the published version cause you can publish over an old version.

I'm having trouble visualizing how skipBumpCommit would work or what the end result would look like. To run shipit you have to change the version in some way, so i can't see how you could get out of that commit.

What do you think of shipit skipping the bump commit when the version in package.json is something like 0.0.0-development?

1. Package starts at 0.0.0-development

2. you run version it returns the bump based on PRs, it returns anything (patch, minor, major) - lets say it's patch

3. Changelog creation - (0.0.0-development => 0.0.0). But you don't want that to happen? Instead add under the '0.0.0-development' changelog title?

4. publish hooks time - it would 0.0.0-development => 0.0.0 and publish. but you want development to be detected and skip publish step all together

5. make a github release - Instead of creating a new release, update the old one with the new commits

6. Package stays at 0.0.0-development until ??? while changes accumulate

Two options if thats what you want:

1. Simply do not run auto shipit until you want to start releasing and publishing. Still add the labels to your PRs. When you are ready add auto shipit to your CI process and it will include all the labels PRs in your first release.

2. Write a plugin. This behavior is pretty unique and doesn't really conform to the way npm does versioning. I think you could make a plugin to accomplish this stuff. Although I would probably have to add a hook or two for you to utilize.

A package with a version of 0.0.0-development indicates the following:

• The highest published NPM version is considered the "current version"
• The version in package.json should never be changed

When a new NPM version should be published, Auto should increment the "current version" using npm version $(auto version).

The changelog uses the "current version" from NPM (instead of from package.json).

As always, a new Github release is created for every NPM version.

Am I being clear enough?

The version in package.json should never be changed

To publish new versions to NPM you have to change this. The only way to increment the "current version" and never change the local one would be to:

• change it to current version (NPM)
• do the bump
• change it back
• but since it the tag would be the bump current version do ???

I'm pretty sure I understand your use case.

a. you don't want to publish a bunch of versions while you are developing a feature over multiple PRS
b. once a new version should be published you want all the changes included

In my eyes we already give you two ways to do this:

1. use onlyPublishWithReleaseLabel. new versions aren't created until you add this label. So you could look at any PR/code without the label as VERSION-development

2. as you are merging PRs for the big feature use skip-release until you are ready for a version, then just merge a PR. The new release contains all skipped PRs. In this case you can look at adding the skip-release label as signifying that your version is VERSION-development

How does this differ from the behavior you want?

It seem to me to boil down to: you want to add -development to your version to start skipping releases and remove it when your ready for all the changes to be released at once.

to accomplish my last sentence you could probably make a plugin that uses beforeShipit to check for the presence -development in the version and throws an error if it's present. This would prevent shipit from moving forward until you remove -development.

The only problem I see with this is that it would also fail the CI job.

Interesting interpretation, but not quite what I intended. 😅

I'm basically describing how semantic-release works.

I _should_ have said "The version in package.json is only changed temporarily in order for npm publish to succeed" (instead of "The version in package.json should never be changed"). All I'm really trying to do is avoid the bump commit altogether. :)

Ok so the state you would end up in is:

repo: only ever has verison 0.0.0-dev

npm: Has the real version all the time (this is whats used for anything)

correct?

Kinda like

        if (auto.options.skipBumpCommit) {
          // get published version
          // change local version to publish
        } else {
          await execPromise('npm', [
            'version',
            latestBump || version,
            '-m',
            '"Bump version to: %s [skip ci]"'
          ]);
        }

        await setTokenOnCI();

        await execPromise(
          'npm',
          !isPrivate && isScopedPackage
            ? ['publish', '--access', 'public']
            : ['publish']
        );

        if (auto.options.skipBumpCommit) {
          // change local version back to DEV
        } 

        await execPromise('git', [
          'push',
          '--follow-tags',
          '--set-upstream',
          'origin',
          '$branch'
        ]);
      }

Yeah, looks good!

auto v4.0.0 here we come lol. Looks like I'm gonna have to split up the publish hook. This will be another plugin

If you want, you could bake this feature into Auto for now, and wait to split the publish hook until another plugin needs it too. 😛

This should be possible via plugin now with #247 (the semver ability). The commit message thing requires a bit of config changes and doesn't really get you much. Closing but open to PRs!