I am trying to figure out what "version": 1 or "version": 2 at the end of a Package.resolved file generated by Swift Package Manager stands for. I have two workspaces and sometimes the Package.resolved files have both version 1 or 2, sometimes different versions.
What kind of impact has having different versions and what is causing the version change? Is it possible to have the same versions for both?
I've done a bit of research and it seems Apple changed the format of the Package.resolved file with version 5.6 of the Swift tools. Any version of the toolchain can work with version 1 but you need >= 5.6 to work with version 2. See this forum conversation
https://forums.swift.org/t/using-swiftpm-5-6-and-supporting-older-versions/55708/9
As I said in my comment, it's probably best to ignore what's in that file and not commit it to your source code control. One of the comments in the above forum thread mentions that you might want to commit it to ensure repeatability of builds, but that is a fragile solution and if you want to build with exact versions, you should do this in the Package.swift file.
Addendum
You'll get mixed versions because, if resolving a package means no changes, spm will not overwrite the old Package.resolved.
Related
I'm new to Swift Package Manager but I pulled a project from git with different people working on it and I can't find the package.swift in it. On a further check, I realized package.resolved was in there.
Do the two perform the same role?
When I build, I don't see a Sources folder, Even though I see the Packages in Xcode. Is that normal?
New sub packages eg. (FirebaseAuth from Firebase) that I now add to the dependencies are not available for use in the project. Seeing "No such module" errors
For the first question:
It's like Podfile & Podfile.lock for instance (and many other dependency managers).
The Package.swift let you tell what you need.
The Package.resolved let you know what was downloaded/used.
The Package.swift is the "command", "developer settings", in this case it's "Swift code", and the other one is just a "text file", a manifest, a written record of what is really used.
In the Package.swift you might need a PackageA. But PackageA might need SubpackageB. But it would be a pain to add manually all the subpackages. At a higher level, you don't need to know them.
In the Package.resolved there are written there.
You might specify a version, or a minimum version for a Package: like "1.0.0" up to "1.xx.xx", to get the fixes/revisions when updating the dependencies.
In the Package.resolved you have the exact versions that have been downloaded/used.
This allow you, if you don't do an update, to recover the exact same version of the packages.
For instance, if you have the "1.0.0", there is a "1.1.0" available that fix an issue, you might want to be on that specific version "1.0.0" to reproduce the issue, or if the "1.1.0" introduces a new bug, you want to keep that 1.1.0, and not perform an update until otherwise. And when you buil to release the App, you keep using the same version of the packages, the one you used/tested with (until there is a manual update).
I want to install a previous, specific version of k8slens (https://k8slens.dev/) but impossible for me to find this (neither for mac nor windows !) Do I have to download the source code and rebuild it? Even with this there is no "install" section in the makefile !
Why is it so difficult to find a specific version?
Yes, you can easily download the source code for a specific version tag and the compile and use it. The list of tags is here.
Once you get the source code of your desired version you can generate the binary with :
make build
And then simply run that binary to get your required version. Just know that install simply means copying a compiled binary in a known Path of the system so it can be executed. There is nothing special about it.
The question was made some time ago but just in case you haven't reached the answer yet, One thing I did to solve this problem was that i went to the lens repo : https://github.com/lensapp/lens/releases and search through the old release versions seeking for a binary asset (.exe) (the news version provide the source code but not the binary) then i managed to find the binary of the version 4.2.3. ( release in Apr 26, 2021)
Worked perfectly for me. Hope it helps
i'm having some issues getting modules to work on my app - I keep on getting told that the requested module cannot be found.
It is entirely possible that i'm not installing the modules correctly - so, for the purposes of this question:
Once i've downloaded the zip file from git hub using the green "download" button, what do i do to import the module into my project? Not how do i tell tiapp.xml to use the module - just what do i do to install it?
Can you please run through using the facebook module found at https://github.com/appcelerator-modules/ti.facebook
thanks!
Inside the zip file of the download you'll see there is a folder called modules. This is the same folder that is in your root of the project.
So, an iOS module should be installed in the /modules/iphone folder. Once added, you can add Facebook to your app like this:
<module platform="iphone">facebook</module>
If you want to specify a version you can do so like this:
<module platform="iphone" version="1.1.0>facebook</module>
note: I made up the version number
You can also add it through the tiapp editor in Appcelerator studio, although it doesn't always seem to find the module. This might be a bug in studio though, usually it works great.
HMMMM
Two main issues here, one directly relating, the other less so.
Issue 1
The link i gave to get the codebase from github is wrong - well, it gets the codebase, but not in a form that can be used as a module. It is, in fact, the uncompiled version.
Versions for download can be found here.
So that takes care of issue one, what about
Issue 2
The latest version for use is a bit broken. Seems someone (from the appcelerator team???) decided to make the latest 6.0.1 release have a minsdk of the (at this time) as-yet-unreleased version 6.0.0, and sets the apiversion to 3.
This breaks the current release of 5.5.1, so for anyone reading this prior to 6.0.0 for appcelerator, you will want to use this release version.
I just published a package to nuget but realize I forgot to include a css file. My versioning is tied to the library I'm packaging (which I don't own) so I can't really increment it.
How do I force a re-push or what's the recommended thing to do in this scenario?
Found out an answer to my own question.
There is apparently no limit on how many version places there are so you can simple append yet another version place.
So for example if the package you're packaging is 0.0.1 you can upload another one 0.0.1.1
When creating a nuget package, the version in the file name of the nuget package seems to come from the AssemblyInfo file in the web application project. I have also created a version attribute inside the nuspec file.
What is the relationship between these two version numbers and are there any conventions attached?
With regards to convention, the NuGet software itself, and the semantics it applies to packages in the gallery, does versioning as described by SemVer.
Specifically you can designate beta versions by suffixing your nuspec version number with "-beta.4" or something. For example, see how the gallery displays the latest version of AutoFac, and compare how it displays an old release (note the text "This is not the latest version of Autofac available." Edit: The gallery no longer seems to provide any special message for non-current versions) and an old PRE-release version (with the text "This is a prerelease version of Autofac.").
Unfortunately, the AssemblyVersion in AssemblyInfo.cs may not contain letters or hyphens, so it can't be used in this way. However the AssemblyInformationalVersion MAY have letters and hyphens in it and, if you provide it, NuGet will use that instead of the AssemblyVersion to replace the $version$ token in your nuspec file. What's more, the AssemblyInformationalVersion (also called the "Product Version" if you check a DLL's details in windows explorer), at least to me, better represents what the NuGet version should match.
I have a slight concern with this approach in that I'm expected to leave the AssemblyVersion the same through various beta iterations and a final production iteration of the AssemblyInformationalVersion, which means I'm allowing several different versions of my DLL into the wild that may behave differently or incorrectly, yet are all identical as far as the CLR is concerned (the CLR only cares about AssemblyVersion). In practice, though, this happens frequently (including with the AutoFac packages described above) and it doesn't seem to cause a problem.
See the two excellent highest-voted answers to What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion? for more info on AssemblyInformationalVersion and friends.
There doesn't need to be a relationship between the assembly version and the nuget package version. By convention, many maintainers use the same number for both.
The convention for using the same number is also the nuget.exe default if you have no nuspec, or you use nuget.exe spec to create a tokenized nuspec file. However, if you replace the $version$ token with a value, then that value will take precendence and will be used in the package file name.
You can also set the version on the command line, which takes precedence over all of the above.
More info on Xavier's blog: NuGet $version$ token explained