CODEWITHSUNDEEP
gitbranchversioning
TheUnexpected
TheUnexpected

Reputation: 3167

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:

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.

Upvotes: 0

Views: 699

Answers (1)

knittl
knittl

Reputation: 265339

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

Upvotes: 1

Related Questions