I’m writing a library. It’s a completely rewritten version of another one, to suit my needs (PCL compatibility, mainly). However, the API will be completely rewritten, as I’ll need to change a lot of stuff around for PCL compliance. Also, as it is a rewrite, I won’t be able to just start from the library and just change it bit by bit, as I typically see with forks. I tried that, but it just didn’t work.
So what should I do? Should I fork here or should I make a new library?
13
“It’s a completely rewritten version of another one […]”
Strictly speaking, something completely rewritten isn’t considered a version; at least not in computing where we take “version” somewhat formally. For example, it is misleading an incorrect to call Linux a “version of Unix”. The word widely accepted for this is “clone”.
Something rewritten also cannot possibly be a fork, even if it resembles the original to the point of being a clone (such as by having similar or identical interfaces).
Since you’ve tried modifying the original and it didn’t work, and then embarked on a rewrite, that bridge has already been burned: the rewrite isn’t a version, and so it cannot be considered a fork. It isn’t even a clone, because the interfaces are different!
It’s a new library which covers a similar area of functionality as the old.
If the library internals are complicated and worth reusing, and the new interfaces can be easily adapted, to use the existing internals, then a case can be made for extending the library: keep the old interfaces in place (perhaps providing a way to remove them at compile time to save space). If that approach was feasible for this library, then you wouldn’t be doing a complete rewrite, though.
So what should I do? Should I fork here or should I make a new
library?
With both options you’ll be left working on some form of new iteration of your old project. The differences lie in other things:
- Forking would leave you to start working with the last version of the code of the previous iteration, so here it depends on how similar in structure / design you envision the new iteration in respect to the previous one. If it’s too different, you might opt for starting a new library instead of forking.
- When you create a new project you are detaching yourself from the source code repository of your previous iteration. Forking would keep your projet in the same repository, enabling you to rollback to or get from a specific historial version. Advantages of not forking, from this aspect, would probably be better order and organization and less clutter of your new repository as you start fresh.
- If this is an open source community driven project, then you should consider forking or not also based on the fact that the decision will in itself convey content to the community. Forking would indicate the new iteration should be thought of in terms of being a direct continuation of the previous one. Starting a new separate project would indicate to the opposite.
Do you have tests? If so, how tightly are they bound to the code rather than the behaviour? I’d work through the tests if they work at the behaviour level.
If you don’t have tests then (please) write some and use that to drive out what you need. It sounds like a rewrite, so apart from reusing ideas it might be better to say that it’s a “major release number” and therefore a new version altogether.
Given that you are essentially re-writing everything from scratch, you should create a new project. Forking would imply that the two share enough similarities that sometime down the line, you could share features, take some new addition here or give some fix there. That’s clearly not going to be the case.