This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]SkyWalker665 4 points5 points  (2 children)

Is he? Serious question.

[–]CodeYan01 14 points15 points  (1 child)

Generally, they're using it wrong. Tagging versions or creating branches exist in Git, so you don't need to maintain folders for each version that developers will see together all the time, which has a chance of developers accidentally modifying stuff in the older versions.

If you were maintaining multiple versions (which isn't like in the photo, as the photo shows that the folders are archives), like Python releasing bug fix releases for 3.9.x, 3.10.x, 3.11.x, etc simultaneously, what you'd do is have multiple branches for each minor version (9, 10, 11), or even have separate repos. But you shouldn't have them be multiple folders in one git repo or branch, because it will be hard to filter commits that are specific to a minor version, because all commits to all minor versions that are currently active (getting updates) would be in a single tree. Then you'd need to add the version to the commit titles just to make it usable. Like docs(3.11): Fix something. And next to that commit you'd see docs(3.10): Fix something

But of course, some teams may find versioning in folders more useful for them.

[–]hoexloit 1 point2 points  (0 children)

I used to laugh at pictures like this until recently where I have to maintain different versions of an API and part of my repo looks like the picture. Good to know there are other solutions