gitmodules and release version
pirate486743186 opened this issue · comments
The modules work in the release version? It is missing .git and the command doesn't seam to work. I tried doing a git pull but nothing seamed to happen.
I'm not a programmer, either it's broken( you removed .git) either you left out something from the instructions.
You're probably missing this step:
After cloning, run git submodule update --init to set all of these up. You can also use this command whenever the submodules need to be updated.
See this guide for more details and troubleshooting: https://vsix.dev/wiki/Guide:Compiling_VVVVVV_on_Windows_with_Visual_Studio
i'm talking about the release version , not the git version.
This
https://github.com/TerryCavanagh/VVVVVV/releases
There's nothing to clone here. And i'm on Linux, but this doesn't matter at this step.
Yes, the zip and tarball don't include submodules. You will have to either:
- Download each dependency manually.
- Clone the repository instead. If you want to be sure it's the release version, do
git checkout 2.4.
The "Releases" on Github aren't the place to get the game - the zip and tarball added to the release are just automatically added by Github whenever a release is tagged, and apparently aren't complete enough by themselves, so it's better to clone it via git if you'd like to compile the game for yourself.
Or you can also get VVVVVV via its official distribution platforms like Steam, itch.io, etc. If you need a free version, there's also the Make and Play edition.
Would be great if the releases actually contain a complete tarball. GitHub Workflow can automatically do that on every release if configured (like this), we can just take this file with a few modifications and I'll be setup. I'll submit a PR, but this is my first time touching workflows so I'll need some time.
Would be great if the releases actually contain a complete tarball. GitHub Workflow can automatically do that on every release if configured (like this, we can just take this file with a few modifications and I'll be setup.
We can do that manually but that doesn't prevent GitHub from automatically including links named "Source code" which don't have the submodules.
We can do that manually but that doesn't prevent GitHub from automatically including links named "Source code" which don't have the submodules.
Doesn't matter though, a tarball from a workflow will be a separate file. Anyways the PR is up.
Either way the release process is the responsibility of @flibitijibibo so he gets to decide what should be done here.
I think this will be a total mess when trying to debug. You are introducing dev versions of dependencies. You are also breaking the convention of dev/release version separation.
I would recommend to drop the submodules and just directly copy an exact version that you hand picked. Wasn't this way earlier?
I think this will be a total mess when trying to debug. You are introducing dev versions of dependencies. You are also breaking the convention of dev/release version separation.
Okay, assuming for the sake of argument that this is true...
I would recommend to drop the submodules and just directly copy an exact version that you hand picked. Wasn't this way earlier?
I don't see how this solves any of those concerns that you just brought up. Yes, this is what we did before we switched to submodules, but we were also using interim commits of dependencies.
Regarding dev/release version separation, that is a totally separate concern that has nothing to do with which method we choose to manage our dependencies.
You are using floating dev versions in a release?
You are mad, not even arch is doing that. A release should be frozen for real, or it's not really a release. You are making your lives more miserable for no real gain.
Do what you want i'm not your dad. What you are doing is a bad idea.
The out-of-tree changes include a VS2010 fix and a memset, both of which are documented and intend to go upstream - we'll update the submodules when the patches are in, in which case we'll be in sync again, or we'll fork and update the URLs, again putting us back in sync.
If this was something like the kernel I'd agree, but this is a game with prebuilt binaries... I'm still going to make the cleaned up zip but I'm going to cut this short before I read something that changes my mind here.
VVVVVV-2.4.zip is now included in the release: