Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard version should be atomic #528

Open
maxevilmind opened this issue Jan 17, 2020 · 2 comments
Open

Standard version should be atomic #528

maxevilmind opened this issue Jan 17, 2020 · 2 comments

Comments

@maxevilmind
Copy link

maxevilmind commented Jan 17, 2020

Dear all,
recently, I've faced issues related to the atomicity of the standard-version command when releasing my projects. In some situations, a certain part of the command like bumping versions and creating tags might be successful, but postbump script might fail. As a developer, I would expect standard-version to be atomic and do not bump versions or create tags if at least one part of the command has failed (postbump included). Standard-version should roll-back all the changes it made in case of failure.
i.e: Current behavior might trick you in a situation when you do npm run publish with the partial result of the standard-version while you expect atomicity.
Let me know if this sounds like a fair point I can work out a PR for that.

@jbottigliero
Copy link
Member

Hey @maxevilmind – I think you bring up a good point around standard-version's atomicity and it's something we should investigate.

In the particular case you've provided:

a certain part of the command like bumping versions and creating tags might succeed, but postbump script might fail

That seems like a different bug (or it's just me reading into your word-choice a little too much), the current processing is:

index.js

    // ...
    .then(() => {
      return bump(args, newVersion)
    })
    .then((_newVersion) => {
      // if bump runs, it calculaes the new version that we
      // should release at.
      if (_newVersion) newVersion = _newVersion
      return changelog(args, newVersion)
    })
    .then(() => {
      return commit(args, newVersion)
    })
    .then(() => {
      return tag(newVersion, pkg ? pkg.private : false, args)
    })
    // ...

So I'd expect in the case of an error thrown in postbump you'd never reach tagging. That said there are certainly lifecycles that will alter local files and not revert them to their original state when an error is hit in a later lifecycle.

@maxevilmind
Copy link
Author

Thanks for your response, @jbottigliero.
Good to hear that you liked the idea, I will dig into the code to get more familiar with the logic and work out a PR with a POC soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants