1

I am making a JS library that creates graphs and charts using canvas. I have hosted it on GitHub as a public repository.

So after looking at some other related questions, I have figured out two solutions to keep active releases separate.

Method 1:

  • The master branch is named dev.
    • All work happens in this branch
  • Once a release is ready, a new branch is made.
    • Its name would be Version {Major.Minor.HotFix}

Method 2:

  • The the master branch is named Version {Latest Version Number}
  • There is a dev branch.
  • Once a new version is ready, the master branch is branched off and the dev branch is merged into the master branch and renamed. Then the work for the next version starts again on the dev branch.

Which one would you recommend? Which one will be clearer to contributors/users?

I hope I am clear, if not, please let me know!

Thanks!

Improve this question
2
  • What do you mean with "active releases"? Is that releases that are being used in other projects? Or releases that receive new feature updates? Or something else? Commented Feb 1, 2022 at 6:49
  • @BartvanIngenSchenau I mean releases that people may still be using or critical bug fixes may still happen on. Not the latest but still active. Commented Feb 1, 2022 at 15:29

2 Answers 2

Reset to default
2

I don't think you're going to have much fun renaming branches like that.

Why not stay simple? master branch is your root. Create branches off it for your features or releases (call it, say, dev), then you can branch off dev with your feature branches. As features are developed and good, you PR/merge them back into dev. When you got everything working in dev, PR/merge dev into master and tag master with your release number.

You continue to work in dev, creating new identified feature branches (by identified, I mean you'd create a branch off dev called feature/adding-pie-chart or something similar. Get the pie chart working in that branch, then PR/merge it back to dev. Lather, rinse, repeat. If you get new contributors, they would branch off dev, do their do, then PR it back to dev where you'd have a chance to review.

Improve this answer
3
  • Ok so I think this is what I needed. Please let me know if my understanding of tags is correct. Once I tag the master branch as the release number (version number), people can still go back to the old versions right? Commented Feb 1, 2022 at 15:33
  • 1
    @TalinTheDev, Yes. a tag gives a user-friendly name to a particular commit. The tag remains with that commit, even when more changes are added to the branch(es) that the commit is a part of. Commented Feb 1, 2022 at 15:36
  • So, basically, tags are read-only branches... without being branches? Oof Commented Feb 1, 2022 at 15:38
1

Method 1 is trunk-based development with branch-for-release. This is a well-known concept. Even if an individual developer doesn't know it, there are plenty of resources for understanding it and working through any problems.

Method 2 is, as far as I know, not a widely used pattern. The renaming of branches is unexpected and could lead to confusion.

Given these two options, I would recommend Method 1.

Improve this answer
3
  • Yes, I thought of method 1 first but I wasn't sure. Thanks anyways! I accepted Mike's answer because he answered first but your answer helped me decide too. Commented Feb 1, 2022 at 15:38
  • @TalinTheDev if it helped you too, you can upvote (this doesn't change naything to your answer selection) Commented Feb 1, 2022 at 23:19
  • I would, but I only have 13 rep... Sorry! If you upvote, my question, I can upvote yours! Commented Feb 2, 2022 at 0:37

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.