Alternate versions of the crates which allow regular breaking changes

[ripytide]

Inspired by #2316 but I didn't want to sidetrack that issue so I've opened a new one.

I feel like a lot of the big issues of this crate are still around due to the limitations of not being able to make breaking changes. I can understand the desire for not making breaking changes but as a contributor wanting to improve the codebase it's a big blocker.

Therefore, would it be possible to create a secondary set of crates as copies of the base image-rs crates under the image-rs github org which remove this limitation by explicitly stating that breaking changes can be made at any time? I would be much more willing to contribute toward that set of libraries and believe it would massively increase the development speed (at the cost of stability).

They could simply be the same crate names but with unstable appended for example: image-unstable, image-core-unstable, etc..

[HeroicKatora]

For fully unstable versions, would it be suitable to use git dependencies with tags? That could be quickly organized with a development branch separate from the main branch. The missing link with the idea seems to me how to shape and incorporate the feedback to iterate quicker, not merely write more code. Similarly keeping it in the same repository tree would be beneficial for maintainence. Otherwise, code might diverge faster than it can be merged / backported / …. Although if it happens to effectively result in a split towards a more attractive branch then that doesn't sound detrimental.

[ripytide]

Using a different branch comes with the disadvantage that issues/pull requests would all be on the same github repo which could make things quite confusing for both users and contributors. I think the unstable versions we would still want to use cargo publish with version numbers, the only difference would be that we would make breaking changes whenever it would be an improvement and then also release those changes in a new version as soon as they were ready.

An analogy might be the debian linux's release cycle vs arch linux's rolling release cycle where only the latest version is supported.

[ripytide]

Ideally, the unstable version would actually be able to get to a stable state faster than the stable version since it would be able to change faster, so maybe the unstable designation is a bit of a misnomer. (Assuming that there exists a stable state for such an image library in the first place).

[fintelia]

Do you know of any other Rust crates that do this? Or libraries in other languages for that matter?

To me, this sounds like maintaining a fork of our own code. It would come with all the downsides that forking entails: development effort would be split across the two codebases, and as they diverged farther apart it would become increasingly difficult to merge changes from one to the other.

On the other hand, the thing about a fork is that if anyone wants to try this, they don't need our permission since image is open source and the code wouldn't have to live in the image-rs organization.

[ripytide]

Yes essentially it would be a fork but it could still be helpful to the original version in that if things go well in the unstable version then that gives confidence that the changes could be brought back to the original version. Would you rather I made another github org for the forks or would you like to keep the alternate versions in the image-rs org?

[fintelia]

I think a different github organization or a personal repo would be best.

[ripytide]

Okay, I've created the alternate project over at https://github.com/imageun/imageun