Default unityVersion to the branch's m_EditorVersion in ProjectVersion.txt

I have working code (pretty simple) to read m_EditorVersion from ProjectSettings\ProjectVersion.txt. I’m using this as the input to with: unityVersion. Something like this could be the default if unityVersion is not specified. Any thoughts on that? Seems to be in keeping with the goal of having things work out of the box, but maybe you want to avoid parsing this file? Maybe in production people want to use a constant version to build binaries, but you’d think they’d be developing with that version too, right? It looks like the ProjectVersion.txt file has been around for a while (at least 2015), and is automatically updated by Unity when you upgrade. What do you think?

[webbertakken]

I see.

Yes I think you will find that every production-grade project using Nodejs will only change the Nodejs version in CI and docker files when this is proven to work in the pipeline itself, not just when someone installs a different version of node and creates a commit. (yes I have seen people using latest tag too, but no comment)

Lets continue platform agnostic:

I believe these things are semantically different because:

• Your CI pipeline is supposed to work all the time; it is the thing you rely on. A separate pull request is created when upgrading a version, and during this PR also documentation and contribution docs are changed and any incompatible parts will be fixed and from that moment on everyone works with that version. Note that in the review of this PR, people can comment on what is missing. Lastly, production deployment is probably tested right after or even before applying these changes, and from that moment on all features can be based on the new version; everyone rebases on a version that you know that works.
• Your development workflow on the other hand should contain as little hiccups as possible and everyone uses the same version. Nobody upgrades it without also performing the other tasks. If instead you would upgrade and implement a feature but conflict with other developers on their features then you have to manage this mismatch on a non-central location. This is where long-living forks and massive deltas start popping up.

The bigger a team is, the more important these differences become and in some cases entirely different teams are responsible for these two things. If you’re saying my explanation isn’t world-class I fully agree, but I’m not convinced we should change all Unity Actions based on 1 use case that in my opinion mixes concerns. (You’d have to come with objective reasons and why it would work for everyone else too).

If you want to do two semantically different things in the same step, this is possible of course. Nobody is stopping you from reading a file in a step before the build or test step and providing a value (using an output parameter) as the Unity version in Unity Builder and Unity Test Runner.

[webbertakken]

Hey @dogboydog,

I think it’s an interesting idea.

Currently I think this is not desirable for three reasons:

• A change in CI pipeline should always be reflected in the CI configuration. Changing unity version is a major change in workflow. Therefor I would argue that automating version number for unity is semantically incorrect.
• Every change of version requires a separate license, which has to be acquired using a manual task (for personal licenses). This task specifically is currently not easy or desirable to automate.
• It would make the workflow not simpler but more complex to understand when working with matrices.

I think we should close this issue unless we have specific use cases that would require this.