Is it bad to make the contents of a published crate completely different?

help
1

This topic uses the following crates as examples:

  • sevenz-rust - This is an implementation of the 7z format. The author's GitHub account has been unavailable for several months, and it is unclear whether the author is still developing this crate.
  • sz - This is an implementation of the 7z format which I abandoned early on several years ago.

Since I don't expect sevenz-rust to be updated, I came up with the idea of ​​renaming sevenz-rust to sz and releasing it as a new version of sz. This will remove all previous content of sz and replace it with the sevenz-rust.

Is this a bad practice? Or is this an acceptable practice?

2

Bad practice. It’s similar to not being able to delete a crate, just yank them. Having an entirely different project inside of an old one is misleading. Just make a new crate and name it sevenz-rust2. It’s the standard for remakes.

Addendum: This is personal preference. I will also be honest, I was treating these as generic crates, not the actual crates they are. @jofas is giving significantly better advice for the situation.

3

But it's not a completely different project as both implement 7-zip.

Given that sz currently is version 0.0.1 without a discernible user base, I don't see why you shouldn't release a version breaking new release of said crate that forks sevenz-rust, if the latter is abandoned.

4 Likes
4

Personally, I would err on the side of "progress", in this case. There's nothing inherently wrong with publishing a complete rewrite with a bumped version number. Arguably, that's what version numbers are for. In addition, the redundancy of a 2 suffix in a package name with a completely unrelated version number is a big pet peeve of mine. Just be honest and release version 2, already!

On a sidenote, the practice of unrelated groups commandeering unmaintained packages and slapping a 2 suffix on the name is equally infuriating. Because what ends up happening anyway is that the original package gets revived at some point and the foo2 package goes dormant. crates.io is littered with dead-end foo2s.

6 Likes
5

There is nothing wrong with completely changing the content of a crate as long as it is correctly versioned.

I'm not so sure about copying some one else's code and then continue it under circumstances that might make it appear you are the original author.

I can't find the original source code, but according to create.io, sevenz-rust seems to have a Apache 2.0 license, so you will have to abide by the terms of that license.

3 Likes
6

I think that if you bump the major version, and make the big change clear in the README, it's fine.

Major version increase prevents existing users from automatically getting the new code, and clear information will ensure that when they decide to upgrade, they'll notice what's going on.

1 Like
7

It's a good practice, as long as you:

  1. make it very clear that the entire code has changed
  2. make it very clear that this is a fork, and people can look up the original (+link)
  3. and do semver-incompatible version bump

I call it good practice, because it reduces the amount of crates people will have to go through when looking for 7z library.

Keep in mind that you might also have to fork his other library (lzma-rust), which sevenz-rust depends on.

What happened to his github account? Do you know? Self-deleted, deleted by github, or some kind of DMCA bullcrap?

I've checked sevenz-rust code, it looks good to me, but I'm a bit hesitant to use a crate without active bugtracker.

2 Likes