#to_a method is harmful about values HOT 5 CLOSED

as far as I'm concerned Values is in maintenance mode. Whilst I agree with this issue, and think that behaviour isn't the best, I also don't want to break users applications who may rely on this.

from values.

@tcrayford No worries. Since you responded (Hi Tom! Been a while, hope you're well!), may I ask: would you be open to my forking the existing Values gem to allow the codebase to continue, while leaving your original gem alone?

For example, i was considering naming such a fork "values2" and starting the version at 2.0.0.

Alternatively, to avoid a fork: I'd be happy to take over maintenance of this gem, and using Semantic Versioning, restrict any and all breaking changes to a 2.x.y series of versions.

Your thoughts would be greatly appreciated,
-Marc

from values.

Hi Marc,

I'd be ok with a fork, but would rather it doesn't use the Values name. I still use this gem a bunch, just don't have any desire to change it, and want to retain ownership of the name.

from values.

Hi Tom, thanks for responding!

If you have another minute to think about this, I do have a couple more questions to help me understand what would work better for you.

Background
In my experience, when gems, and software projects in general, reach the end of their original development life cycle, generally what forks have done is to pick up in the same namespace and code where the original left off (ie to have class called Value), and to aim to have an easy path to switch between, the original and forked version of the dependency. To make it extra explicit and helpful, I've observed it's great to start a Semantic Versioning version after the original version, to signal the level of backwards-compatibility users can expect in the fork. But this is often not observed, and many long-running forks have overlapping version numbers with the original, which is a pain.

Proposal
Can you say a little bit more about any downsides you are seeing, if any, in the following type of fork:

1. I fork the existing repo and continue development in my fork
2. I make a new gem, which is an alternative to using the original values gem, from this repo
3. The new gem starts at version 2.0.0, a semantic version ahead of the original, signaling backwards-incompatible changes, and not conflicting with any original gem versions
4. The new gem aims for as much backwards compatibility as possible within this framework

Very interested in doing this in a way that is best for both of us (and all gem users)

from values.

Hopes and dreams
If possible, I'd really like to have what you might call an "officially amiable fork", and propose the following structure that would be really awesome:

• You, as the original author, approve of the existence of the new fork, and perhaps contribute to design discussions as your interest and time allow
• I, as the fork maintainer, do not disparage or in any way harm the reputation of the original, and have a clear explanatory document outlining the reasons for the fork, and the differences users can expect to find in each codebase
• Users are provided code, artifacts, and documentation which, as much as possible, makes it feasible and friendly to switch back and forth between implementations

from values.