Default unityVersion to the branch's m_EditorVersion in ProjectVersion.txt about unity-builder HOT 7 CLOSED

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.

from unity-builder.

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.

from unity-builder.

Okay, I see what you mean and pretty much agree.

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.

I'm not sure I fully understand this point, though.

In my case, I have a separate CI pipeline that just makes sure the project can be tested and built with the version of Unity that is checked in. Everyone on the team is using whatever version is in ProjectVersion.txt for that branch. So if a developer updates Unity, Unity automatically changes the ProjectVersion.txt file. So either you keep the workflow exactly in step with ProjectVersion.txt (benefits: git history of the workflow file?), or the build is not using the same version you're developing with (may lead to unexpected results). The ProjectVersion.txt file itself is a record of the version for the project and it seems like Unity parses it to check compatibility. So I guess I see it as comparable to needing to re-specify the version of a dependency already declared in package.json, but I could be wrong.

There's no deployment in this particular workflow, and also we have a non-free license. But I can see how this would be confusing or not useful in some cases like with a free license, so I agree it's probably not appropriate to default the version in this repo.

However, it's easy to achieve without defaulting it in unity-builder anyway for anyone who would want to. Thanks!

from unity-builder.

Which part did you not understand exactly?

from unity-builder.

If you commit a change to ProjectVersion.txt, you are updating the Unity project, right? Everyone that checks out the project will need to update. If you don't automate the version number, your options are to manually update the ./github/workflows/xxx.yml file with the same change, or not update it and have a version mismatch. So why is semantically incorrect to use that version in automation if the developer's goal is to check that the project builds with the version of Unity that you are using in the project? Like imagine if this was an npm tool, and you used it CI. Would you expect the user to re-specify versions of dependencies that were specified in package.json in the CI code? Maybe you disagree with the comparison

from unity-builder.

I'm in complete agreement after your replies that changing the behavior directly in these Unity actions isn't the right call and wasn't trying to argue that point anymore. I was just curious of your reasoning for not recommending the practice even externally to these actions, which I understand better now. Thanks for taking the time.

from unity-builder.

You're very welcome

from unity-builder.