Creating a separate repository for a new major update?

Question

I have a development framework which I'm going to do a major update soon. (to 2.0.0)

I changed the whole design of my framework so it will not be compatible with the previous version at all.

In my case, can it be a good idea to create a separate Git repository for my new major update? And is there any case like this?

I'd appreciate any opinions.

Answer 1

Some real-world example

Yii framework did something like this some time ago. Yii 2.0 was complete rewrite - almost all classes names was changed (due to introducing namespaces) and you can actually use Yii 1.1 and Yii 2.0 at the same time, since these acts as two separate libraries. So Yii team choose to create separate repository (yii2) and separate package name (yiisoft/yii2). This naturally created some conventions - usually Yii 2 extensions are prefixed by yii2- to differentiate from completely different Yii 1.x (usually prefixed by yii-). So far so good - there is consistent naming convention which allows to avoid confusion between framework versions.

But now Yii wants to use semver. This naturally requires to release next major version - Yii 3.0. 3.0 will not be complete rewrite - only some part of the framework will change. There is no sense to create new yii3 repository and new package. So either we have Yii 3 in yii2 repository, or we need to rename repository and package name (which is used as a dependency by thousands of applications and extensions). Both options are pretty bad.

---

So I would not recommend to create new repository, unless you want to treat this as completely new framework (with different name, not just myframework2). Creating new repository and package with 2 as a suffix may look tempting, because it may solve some problems, but in long term it may give more harm than good.

Answer 2

I'd maintain the same repository and the same branch to have the all history preserved. You can use Tags to manage this change, I mean, you will be able to do lots of action with this Tag. For example checkout, sharing, etc.

I think this article could be very handy for you:

https://git-scm.com/book/en/v2/Git-Basics-Tagging