feat(deprecated): add deprecation message

[bcoe]

Unfortunately, I don't have time to continue maintaining standard-version, partially because the tool release-please meets all my needs.

If anyone is interested in forking this repository, and the fork gets some traction, I will happily link to it from this repository (this is where yargs came from, it was a fork of optimist).

[codecov-commenter]

Codecov Report

Merging #907 (66c54ef) into master (6c75ed0) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #907   +/-   ##
=======================================
  Coverage   97.49%   97.49%           
=======================================
  Files          25       25           
  Lines        1119     1119           
=======================================
  Hits         1091     1091           
  Misses         28       28           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6c75ed0...66c54ef. Read the comment docs.

[UnleashSpirit]

Hi,
We used to use this repo for our bumping version and changelog
I can with no doubt understand this deprecation :)

Do you have a basic "migration guide" to release-please ?
What is the standard configuration to do what standard-version does ? (bump version based on conventional commit, tag and changelog)

It seems that CLI is "more complicated", token and url needed what's standard-version does not needed

[TimothyJones]

I've forked standard-version here https://github.com/absolute-version/commit-and-tag-version for anyone who wants to keep using it without changing their process. I also renamed it to better describe the purpose (and avoid using a scoped name / calling it standard-version-fork). PRs and assistance welcome, of course.

I released version 9.5.0, which is the same as this 9.5.0, with one change - the package.json configuration stanza now can be calledstandard-version or commit-and-tag-version (ie, all previous config will still work, despite the rename).

You can get it with npm install --save-dev commit-and-tag-version.

I'll go through the outstanding PRs to standard-version and pull in any that are fixes for outstanding issues and release them this week.

[TimothyJones]

@UnleashSpirit I don't think there's a configuration for release-please that does just what standard-version did - since release-please creates PRs for candidate releases, and will tag it appropriately once it's merged.

I think recommending release-please is a great idea, since with standard-version you still have to plumb it in to your release cutting process, and release-please comes with all of that plumbing. The cost for this is that it's tied to github actions.

If no one else has written a migration guide by the time I finish going through the PRs for the fork, I'll write one.

[jacktan165]

Is there an equivalent to release-please but for bitbucket?

[lazybobcat]

That's too bad for the projects that aren't hosted on GitHub :( I hope someone will maintain a fork, this tool is going to be hard to replace

[alexn-s]

in my opinion release-please and standard-version are VASTLY different in terms of being dependent on npm auth, providing a github repo, ....

standard-versions is not "deprecated" in my opinion and is the only tool that works for me with offline monorepo (pnpm), turborepo, verdaccio repository. i can tweek standard-version how i see fit which is not capable with release-it, semantic-release, ... (they are very opinionated)

💖 standard-version is the best

[alerque]

Thanks for maintaining this as long as you did, I have gotten a lot of millage out of it.

Release Please may be a fine tool for those that want it's workflow, but it is not even close to being a substitute for this tool for many workflows. I'm a bit disappointed in the handling of this actually, but it isn't too late to fix. It would be nice if this repo, already situated in an org namespace) could just be opened up to new maintainer(s) that want to keep up something like the original vision.

As it stands it looks like I'll be migrating some projects to the fork by @TimothyJones and others to git-cliff. It would be nice though if @TimothyJones were just promoted to be a maintainer here where PRs and old issues can continue to be tracked. It is a lot of work to cross reference an old repo with open issues against a new fork.

[colinscz]

For everyone interested, there is a discussion issue where you can give support to a fork of this project and if there is enough feedback we get a definite one assigned sooner than later. :)

#919