Deprecation warning + discussion for standard version successor

[colinscz]

Hi @bcoe

As describe on the pull request here: https://github.com/conventional-changelog/standard-version/pull/907 this project is now deprecated.

There have been some people that offered to fork it and maintain the original purpose of the project, especially for people that cannot depend on Github alone. From what I can see the version by @TimothyJones

https://github.com/absolute-version/commit-and-tag-version

seems to be the most promising.

Could you please pin this issue at the top of the repository for other people to see the current status?

As of now this repository seems to get additional issues and traction and the deprecation message seems to be not transparent enough for everyone. If a successor has been chosen I think it would be beneficial if the repository is archived or set to read-only mode, that way it's quiet clear that there is no more maintenance done on here. Additionally the successor could be mentioned in the README file. For that I think somebody can provide a PR.

Thanks a lot for the work already done with standard-version!

Cheers

[TimothyJones]

Thanks for the kind words! I've written a bit about the plan for the fork here - the tl;dr is "stay true to the original purpose".

If you feel it is appropriate, I'm happy for a link to my fork to be pinned.

[bcoe]

@TimothyJones @cnschwarz commit-and-tag-version does look very promising.

[mgan59]

I'm little late to the party and didn't see the deprecation notice, but had adopted standard-version tooling for some projects. Appreciate everyones effort in transparency and knowledge sharing here to help in identifying how to proceed with our tooling. 👍🏻 👏🏻

[dtieber]

I'm using standard-version for quite some time now and like it better than the suggested release-please. Is there anyone else who'd be interested in forking and maintaining this project with me?

[TimothyJones]

PRs are very welcome for the fork I mentioned above - unless you're planning to take the project in a different direction, where an alternate fork might make more sense, of course.

Since commit-and-tag-version is almost at 2,000 weekly downloads after only a few months, I think the long term plan has to be to find other maintainers so we can keep it alive together (of course, I'm not going to just give commit access to anyone who asks - there'd be the usual open-source trust building on both sides).

You can read about the direction for the fork here

[dtieber]

Sorry, I completely missed your post. That sounds great!

[TimothyJones]

@bcoe I've made PR #930, which edits the deprecation message to link to the fork that I have been maintaining.

Feel free to accept if/when you feel it is appropriate (or edit the text) - I just wanted to make it easy for you by having the PR ready to go 🙌

[TimothyJones]

@stevemao thanks for accepting that PR (and adding me to the organisation).

What do you think the right next move is? Two things I think are worth discussing:

1. This repository still gets issues and occasional PRs from people who haven’t seen the deprecation notice. It also gets automated PRs for dependencies, which seems a bit unnecessary for something that won’t be published. Should we archive the repository?

2. I put the fork in an organisation of mine, but it’s kind of unrelated to that organisation. Now that I’m a member of this org, it might make more sense to move it back here (I’d be happy to keep maintaining it, of course).

What do you think?

[dangreen]

Hi all!

After refactoring of conventional-changelog I have plans to refactor standard-version. One of my goals is to add monorepo support to standard-version.

[TimothyJones]

That’s a good idea, but standard version is deprecated. It might be better to contribute to the fork mentioned above instead

[dangreen]

I'm want to undeprecate it with new major release.

https://github.com/conventional-changelog/standard-version/pull/907

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

I have time to maintaining standard-version, and release-please is also bad for monorepos.

[TimothyJones]

I also have time to maintain it- I’ve been actively maintaining the fork above for more than a year now. I don’t think the right move would be to reopen the old package.

You could ask @bcoe if it would be alright to do so, but usually an author deprecates a package because they don’t want to pass on the name to another author.

[mattpfeffer]

My two cents but given a considerable number of people have already started migrating to the @TimothyJones fork. I think un-deprecating this package will create way too much confusion for the community. Stick with the plan, possibly archive this one.

[AoDev]

Hello @TimothyJones . Thanks for your work on the fork. For folks like me who decide to migrate, is there a short answer to:

"Can we simply swap standard-version (latest = 9.x) for current commit-and-tag-version (current 11.x)?

Might be worth a migration note in Readme.

[mattpfeffer]

@AoDev Not to answer for @TimothyJones but just to add my experience if that's helpful for anyone...

Yes, it's basically a swap-in replacement. If your worried you can start with the initial version which was largely a 1:1 fork and then upgrade.

Having said that, I've recently converted a few more projects direct to latest without issue. Of course my setup may be different to yours but I've only ever had to do the bare minimum to get it working.

[TimothyJones]

Yes, per the changelog - 9.5.0 is almost identical, 10.x drops support for deprecated node versions, and 11.x is a formatting change if you're relying on the exact markdown format in the changelog (I'm unsure on whether that should be considered a breaking change for this tool, but I thought being cautious was better).

It is kinda in the readme:

To migrate, you can drop in commit-and-tag-version in place of standard-version. There are no changes in 9.5.0

But it could be clearer, thanks for pointing it out. If you want to make a PR I'd happily accept it, otherwise I'll add a note next time I'm doing maintenance.

Edit: To be clear, I'm not planning to do anything that would intentionally break compatibility - it's likely to remain a drop in replacement for at least a few years to come.

[AoDev]

@TimothyJones Thanks for the answer, here is a PR: https://github.com/absolute-version/commit-and-tag-version/pull/113