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.
I'm an apprentice software engineer working for a large UK company. I love coding in Java and Node, and I've been forced into the hellish servitude that is DXL once or twice.
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I guess it depends on what you want to optimise for.
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.
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!