Is it ok to keep the "old" version of my program in a branch?

I maintain a program which version is "1.x", on master branch. Now I'm planning a big rewrite of it, so most of the files will be deleted/replaced with new ones, but main functionalities will remain the same. I want to call it version "2.x".

I don't want to create a new repository for it (example, I would lose all the open issues of 1.x that I want to address in 2.x). Instead, I was thinking to:

Branch the master to a temporary 2.x-dev and start making disruptive changes there
When "2.x" is ready, create a branch 1.x from the current master.
Merge 2.x-dev into master.

At the end, master will suddenly become the "2.x" version of the program, while "1.x" will remain on a branch that will never be merged into master.

Is it a good practice or should I do it in another way?

EDIT: I'm not 100% sure I won't make further changes to 1.x after the merge. Example 1.x might remain for somekind of retrocompatibility. But it won't receive any new feature.

Solution

Do you plan further development in your 1.x line? If so, a branch is exactly right. (Due to the nature of the DAG – the directed acyclic graph – there is only a semantic difference between a "fork" and a "branch". Think of a fork simply as a "remote branch" on a different server).

If 1.x is just the historical record and will never be modified again, use a tag (command: git tag) instead.

But you can even combine the two:

Create a tag 1.0 to mark the specific version of your latest 1.x release.
If you see the need to do further work, create new branch from the tag: git checkout -b 1.x 1.0.

If you release a new 1.x release, simply tag the latest state of your branch again: git tag 1.1 1.x