<p dir="auto">in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2636858743" data-permission-text="Title is private" data-url="https://github.com/rojo-rbx/rojo/issues/989" data-hovercard-type="pull_request" data-hovercard-url="/rojo-rbx/rojo/pull/989/hovercard" href="https://github.com/rojo-rbx/rojo/pull/989">#989</a>, we changed Rojo's version number on the master branch to 7.4.4. This is a little odd, because 7.4.4 is already released, is diverged from the master branch, and we are not working towards 7.4.4 on the master branch. If we're going to spend time on this, I think we should use a more appropriate version number.</p>
<p dir="auto">This PR changes the version number to 7.5.0-prealpha, since Rojo's master branch is currently undergoing development towards 7.5.0. We will most likely <strong>not</strong> be making a release of this version - the only intent is better clarity for those running Rojo's latest master.</p>
Due to the rewrite of the plugin's core sync loop and the change for the
Notify backend on MacOS, along with all the other changes in 7.4.0, it
makes sense for us to use a release candidate before actually cutting a
proper `7.4.0` release.
This modifies Rojo's build script to throw a fit if we're building a
plugin with a semver incompatible version. In the process, it moves the
version of the plugin to a file named `Version.txt` that's parsed at
runtime. This should be minimally invasive but it's technically worse
for performance than the hardcoded table and string we had before.
This feels better than a CI check or just manually verifying because it
makes it physically impossible for us to forget since Rojo won't build
with it being wrong.
