Hi, I have a script that allows select through with border select. It works on Daily builds, but something has broken it in Official Builds, hoping someone can point me in the right direction.
I can’t find a Deselect option in 2.78c or 2.79, so this looks like a new feature in the daily builds that does not yet exist in an official release.
Also it’s good to realize we have no daily builds of 2.79, The 2.79 code split from master late last year, and has since only received safe bug fixes. The dailies you do download from builder.blender.org are master builds, and master has many new features and compatibility breaking fixes that won’t make it into an official version until 2.8.
But yeah i can see how the 2.79 version on the current master builds could be confusing, maybe it’s better to hide the version number of daily builds all together and just show the branch/hash it was based on?
The versioning of development builds has been a constant source of confusion. I think we should bump the version number at the start of the release cycle, and have “alpha” or “in development” or something next to the version number, but every time I brought this up there was resistance to it so I haven’t bothered in a while.
For the master / 2.8 branches it’s more complicated since we have no next version number in the 2.7 series, maybe 2.799 or something.
I think just a hash is not enough, that doesn’t really tell you anything without looking at git logs, it should be possible to at least see roughly which version it is without that.
neither does a version number though, if you want it a tiny bit more accessible for end users and make it easy to check if it’ll have a certain commit maybe list it as ‘master 2018-03-06’
Thanks for the info, that explains things.
About the naming, I’m teaching blender online and one of the issues is when I tell students to get 2.79 daily builds the student will sometimes get 2.79 official thinking it will work the same.
I see the daily builds say 2.79 b + some numbers and letters, so I’ll make sure to tell them to get the b version. Will daily builds always be named b? or does this letter change over time? The reason I ask is so students don’t get confused if they’re watching the video and the letter is different in the future.
I agree. Personally I already do something like that for Flamenco Manager and Flamenco Worker. The version we’re running the studio is called “2.1.1-dev”, since we’re on master and not on a specific release.
I think that’s a good idea too!
Perhaps it would help if we just started being a lot more liberal in our use of the subversion numbers. As in, we bump to .1 immediately after a release, then whenever some change occurs that needs version patching, we bump as a default action - in short, we don’t do any more of the silly business about checking if struct members got added, shove a whole bunch of version patching actions into an un-checked block at the end of the function (for the next guy to hopefully assign to a subversion number at some point when presumably something is bad enough to warrant a bump), or other garbage like that. I’ve never really understood why we have such an aversion to changing this number - someone may have explained it once, but obviously, it wasn’t really a compelling enough reason to remember!
I think bumping the subversion number often is fine, I also never understood why that would be a problem. No reason to make the code more complicated to avoid it.
But I still think it’s the major version number that needs to be increased at the start of the release cycle as well, because to me it seems obviously more clear to users (who are used to this from almost all other software) and I never saw a good argument against it.