New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for both 32 and 64 bit versions of vvvv #4
Comments
I checked StackOverflow and people saying:
So we should have two separate packages, one for x86 version and one for x64. What do you think? Should we just create vvvv.x64 package? Or also rename current to vvvv.x86. From my side, i think the easiest way is to keep more actual version (currently it's x86) in vvvv package and create package vvvv.x64 for experimental version. When x64 become stable, we should just replace files in vvvv package, so it's became x64 and create a special package for vvvv.x86. Then we could delete vvvv.x64 or link it to vvvv for backward compatibility. |
i think, having both (vvvv.x86 and vvvv.x64) would be good. vvvv itself could then be a virtual package or dependency pointing to vvvv.x86 for the time being. |
Yes, sounds smart. I will make this to packages after the lunch ) |
I think, the name.64 naming is a little off. At the moment, it breaks Chocolatey's versioning: output from
The vvvv packages are now listed without their .64 naming, but as version 64.29... I think it would be better to add 'x64' or 'x86' as architecture distinction to those packages. This was also suggested in your cited article. Another solution would probably be to write 'vvvv-64', using the dash or some other unambiguous character to keep it with the package name. Edited: I misread the original suggestion. |
The dot divider is currently standard in Chocolatey - just check 7zip package ( Comment what you think about this naming and i will close issue. |
I think, it's fine now. Thanks! |
Beta 29 (and probably future versions as well) are available in both 32 and 64 bit. I am relatively new to chocolatey, so i'm somewhat unsure how to add this to the packages. But it would be awesome to support both architectures.
The text was updated successfully, but these errors were encountered: