restructuring, versioning, etc

[johnnyquest]

People seem to use 0.2.5 (?) instead of getting the latest dev branch. Maybe we should get rid of versioning altogether, it doesn't make any sense anyway.

Or we could get back using versioning but that should probably the equivalent of doing "daily builds" or something very frequent, which is essentially the same thing as the dev branch.

On the http://qlab.github.io/qLib/ page --

• emphasize dev branch download button over "versioned" button buttons for "latest version" and "experimental"
• installation on page should say see README.md (and link to it), git blahblah could be removed, or de-emphasized (git people know it anyway, others don't care)

[bxyldy]

I wouldn't mind an upticked tag when you guys push to the dev branch... at our studio, I have the github repo as a submodule in our local package repo; every time I pull, I uptick our completely arbitrarily-numbered package version, but it would be handy to have better correspondence with your dev branch.

(We use rez for package management, and our qlib package wraps some studio stuff around your vanilla stuff)

[johnnyquest]

Yeah, maybe we could still stick to versioning, and bumping the version every week or so... (or say very frequently)

The original idea was to do "releases" (where we'd do some pre-release checks, having milestones and stuff, all seriousness, etc), but let's just face the facts, that didn't work out at all. And I don't like the idea of people using stuff like version 0.2.5 which is probably years old.

[johnnyquest]

@bxyldy what kind of package versioning scheme do you do internally?

[bxyldy]

syntactically: https://github.com/nerdvegas/rez/wiki/Basic-Concepts#version

formally: major.minor.bugfix.hotfix

informally, for our rez package, it's major.minor.qlib-major-minor.whatever

theoretically: 0.3.25.yyyyddmm-vv based on a whenever I do something to the package (ie, merge commits after pulling from the dev branch submodule)

and actually: anything, cuz i'm maintaining it for only a handful of artists and i'm not in pipeline :)

[johnnyquest]

ok, so seems like we'll be doing some restructuring that will happen incrementally, but what we'll have most probably is something like this --

• rolling releases (releasing often and with versioned tags, etc)
• restructuring the whole "experimental/future/base" thing (experimental/base should be enough)
• instead of folders we'll just use another branch as "experimental" (the equivalent of the current "dev branch")
• there will be way more frequent transfering of nodes from the experimental branch to the base
• we can just use node versioning if we have to do some change that would break backwards-compatibility (discuss: even if we change parameter defaults?)

(@gadfly16 i think this is more or less covers what we talked about right?)

[gadfly16]

Versioning is very important in my opinion. It expresses compatibility for the masses. With it we make it possible to people not or less experienced with git and HDA versioning to shape up their own asset enviroment with ease.

For example now that we are going to restructure out folder structure and transition to rolling releases it is really meaningful that we are bumping to 0.3.0.

[gadfly16]

I created a milestone for 0.3.0. Please collect all the resolvable issues that you want to fix under this. The general description and discussion of the release is under #501 . Close this issue if you feel that appropriate.

[johnnyquest]

I'm closing this ticket as I think we got this sorted :D (both versioning of OTLs/HDAs and by switching to a rolling release approach overall).