How do YOU version your file names?

According to wikipedia, looks like the standard is like this: 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2 ?

I wasn’t raised as a programmer, so I’m finally trying to learn myself on best practices. :blush:

As many standards as programmers :wink:
It also depends on how many versions you expect to have - the most important thing is others can immediately understand how your versioning works, and it should make your life easier.
I often use one digit less: majorversion.minorversion is enough for me.
Also include a text with the release notes history.( a list of all what you have added/fixed per version)

But these days I try to have all my versioning done by Git / Bitbucket, so I don’t have to worry about it anymore.

Hmm, so if you use Git/Bitbucket, does the way touchdesigner auto-names files not come into play?

names matter less (for internal work that is) when using something like git since your commit has a unique marker. Git keeps track of committed files, so every time you want to save a working state you commit your work (usually along with a helpful message about what you did).

Each commit is something you can revert to and revisit… in this model your toe file might have the same name across multiple commits, but the version you’re recalling is bound to where you are in your git tree.

To add to Matthew’s points, names matter a lot less and we use TOX files to split out all of a project to external tox files, then multiple people can work on a project at once and only save the tox files they are working in on (and you just have to prevent people from working in the same tox). 2 bonus things I like:

  • scrubbing through commits in something like Github Desktop or in command line, you can basically jump through different versions of your project by switching the current commit you’re on. So if you deleted something and need to see it again, jump back to that commit, check it out, copy what you need, then jump back to the latest commit and paste or continue working. Combined with TOX files means you can roll back only specific parts of your project if you find issues, instead of rolling back the whole thing.
  • getting into the habit of production pipelines where you work in branches, merge stuff into a stable master that you stage and prepare to deploy onto your installation system. That way you can work for a while and only on your command have new stable files on your installation system (as opposed to something like dropbox that is constantly pushing and pulling files).

Thanks guys, very useful infos!

Does one of these git services work better for touchdesigner files specifically? Or are they all pretty much the same?

Use bitbucket at Obscura, and Github on my own projects - can’t say that I’ve seen any differences. Github has a better UI, and it’s the tool I usually go to when I’m working on collaborative projects outside of work. Bitbucket can use several different GUI tools, but I ultimately end up mostly using the command line.

I think there’s a pricing difference as well - if memory serves, github allows unlimited public repos, and bitbucket unlimited private.

I used gitlab recently and it was nice as well and has free unlimited private repos as well. We end up sticking with GitHub though since there’s github integrations for like everything and the Github Desktop app is pretty decent.