DEV Community

Cover image for Handling multiple implementations of a product
Jake Lewis
Jake Lewis

Posted on

Handling multiple implementations of a product

#discuss #git #help

While I'm aiming for general, non-specific solutions, I am using the real example of wanting to re-write my Java logging library

So you want to rewrite your Java library in Node...

I've recently run into the case where I want to reimplement an existing project in a new language, and I'm trying to decide how best to manage the new code in relation to the existing product.

My initial thoughts were to simply create a new repository; this having the advantage of clear distinctions between project history and issues.

java-repo
    > master
        - dir1
        - dir2
node-repo
    > master
        - dir1
        - dir2
Enter fullscreen mode Exit fullscreen mode

I have seen arguments made for keeping all the code in one repository, such as being able to change an algorithm and having all the languages changed in one commit.

project-repo
    > master
        - java
            - dir1
            - dir2
        - node
            - dir1
            - dir2
Enter fullscreen mode Exit fullscreen mode

The last suggestion I saw was that you could have a 'master' branch for each language, but I think that's a bit too unconventional for my taste...

project-repo
    > master-java
        - dir1
        - dir2
    > master-node
        - dir1
        - dir2
Enter fullscreen mode Exit fullscreen mode

What are your thoughts on this? Is there some hot new methodology that I've missed, or is keeping it old-school with separate repos the way to go?

I might be doing a post about the re-write process at some point, so even if it fails horribly it should at least be interesting! 😄

Top comments (4)

Collapse
 
avalander profile image
Avalander • • Edited

I guess it depends on what you want to optimise for.

  • If you're planning on developing both versions actively and maintaining feature parity, at least for a while, having a single repo might be a good idea since, as you say, you can apply the updates to both versions in the same commit.
  • If the new version is just an experiment, or you are going to drop development on the old version as soon as you achieve feature parity, you might want to consider having two repos.

Also, you can always start with what seems the easiest option and switch if your needs change. For instance, you could start with two repos and when the new version is close in feature parity to the old one, you might want to merge both repos if you need to actively develop both versions.

The suggestion of having different masters on the same repo sounds too bizarre. That would work if you were developing a system like Linux, because different distributions use different master branches, but they still want to be able to merge and cherrypick from one master into another, or from a feature branch into multiple masters. In your case, that doesn't seem likely and it's just going to give you headaches.

Collapse
 
jsjlewis96 profile image
Jake Lewis • • Edited

I'm liking the idea of merging the repos once they're close. Currently the idea is to re-write the node version up to feature parity, then go back to the Java version, update it with any lessons learned on re-write, and improve its integration with other logging libraries such as log4j. The Java specific stuff obviously won't be carrying over to the node version.

Separate repos is also probably the easier thing to start from, I'm not particularly keen on trying to split git history from one repo into two...

Thanks for the input!

Collapse
 
jessefulton profile image
Jesse Fulton •

I wouldn't consider what you described above as "multiple implementations of a product." It sounds like two separate libraries - one for logging in Java, one for logging in Node. I'd imagine they are going to have very different implementations simply based on the nature of the languages.

I honestly can't think of a good reason to have two separate code bases in one repository... here are some pros/cons for that approach off the top of my head :)

Cons:

  • contributing to the project involves much more overhead (download 2x code, manage dependencies, environment setups, build processes, etc.)
  • issue tracking becomes more complex (does it impact Java or Node or both? What do you do when you fix the Node but can't/won't fix the Java bug? Do you assign it to the Node Dev or the Java Dev?)
  • Features cannot be implemented at the exact same time. Because of this, the Node/Java implementations will most likely get out of sync and diverge
    • if you try to enforce feature parity, you'll inevitably wind up delaying the release of one while waiting for the other
    • if you don't enforce feature parity, your changelogs and release management will become inherently more complex

Pros:

  • ?
Collapse
 
anaguib profile image
Ahmed Naguib •

Almost all the time, I would vote for having separate repositories. I can only see problems arising from the other solutions, especially if you decided to add more people to work on it.

If you want to keep track of feature changes, have a changelog.

Read next

luxandcloud profile image

Can Facial Recognition Be Trusted for Immigration Control?

Luxand.cloud -

akpevwe11 profile image

Demystify google search

Akpevwe11 -

jimajs profile image

Why I think Python is a Great first Language

Jima Victor -

mjgs profile image

Latest Newsletter: Good Output (Issue #159)

Mark Smith -