How do you configure Xcode (13.2) to add a dependency on a pre-release version of a package?
For example, right now Sparkle has a 2.1.0-beta.2 release which I would like to test in my app.
More accurately stated, I would like to accept 2.1.0-beta.x up to and including the full release of 2.1.0 and I'd like Xcode's "Update to latest package versions" to find the new releases for me without me changing anything in the configuration (eg like you can do with npm).
I can't find any obvious way to achieve this using the Xcode UI. If indeed you can't, is there a way to specify this version range by editing a config directly?
As mentioned here, 2.1.0-beta.2 < 2.1.0, which is why I have tried 2.0.0 in the screenshot.
Related
Hi I want to pin a particular version of dependency in my go.mod, like
github.com/dependecy v1.7.0
And when I run go test or go build, sometimes it gets updated to
github.com/dependecy v1.8.0
The tricky part is sometimes it changes, and sometimes it does not. We would want to pin to an older version because the new version has a bug. Any idea why this is happening?
I believe the reason why this is happening is because you might have a dependency that might have requirement for higher version of the module. From go documentation here
If multiple versions of a particular module are added to the list, then at the end only the latest version (according to semantic version ordering) is kept for use in the build.
You can try the commands listed in documentation or, run go build with -mod=readonly flag. That should help you understand what might be triggering this.
Go modules does not support multiple minor versions of same package in a single module, if added then at the end only the latest version is kept for use in the build.
You can have some dependency which have requirement of higher version and replacing the old one.
If a module out there pushed v1.8.0 with a bug, file a bug or fork the repository as needed.
First, I will describe our setup (it is an extremely simplified version of the corporate development pipeline). We develop a .NET application, which is dependent on some shared components. The shared components typically develop together with the application. We want turn these shared component to NuGet packages.
So, I publish version 1.0.0.4 of package A and want to consume it in my application. My packages.config looks like this.
<package id="A" version="1.0.0.4"/>
So far so good. I probably commit packages.config to version control at this point to remember my dependencies. Now I run the next build of package A, which publishes the version 1.0.0.5. Now I want my application to automatically update package A to 1.0.0.5 before the build.
However, my packages config now contains an exact verion 1.0.0.4 and it's version-controlled. My questions are:
Can I somehow specify that I want version 1.0 or higher in packages config? In other words, can I avoid change of packages.config with every new build of every package?
Can I somehow update the dependencies before build to the the newest version? Can I do it automatically using a script?
I am quite new to NuGet and I come from the ant+ivy/maven world, where this feature is kinid of automatic, so I am still hoping I am missing something obvious in NuGet, although scanning through the discussions on stackoverflow doesn't sound too encouraging.
I've found Using Nuget in development environment - best practices / how to and How to automatically update NuGet packages to latest available version and NuGet issues with packages.config, project references and the solutionwide packages folder, which do not give clear answers.
You can use the allowedVersions attribute to automatically use newer package versions within a range, like this:
<packages>
<package id="SomePackage" version="2.1.0" allowedVersions="[2,3)" />
</packages>
In this example, any package from the 2.x series will be used, but not from the 3.x series. You can be more specific with the contraint e.g. `allowedVersions="[2.1,2.4)" if you wanted to take any package from 2.1, 2.2, and 2.3 but not 2.4.
See http://docs.nuget.org/docs/reference/versioning for more details
I don't think you can change the packages.config to implicitly allow a higher version. Also, the project files have references to the packages folder which include the package version in the path, so those need to be changed after a package update.
You can perform an update of the packages.config and the projects files by running nuget update.
You could automate this in the nightly builds and checking in the resulting changes as well. However, it's debatable whether that's a good idea. At the minimum, you should gate the update operations by running a build to make sure the new version doesn't cause a build break.
I've recently released version 4 of SBJson. This is a new major version that is not backwards compatible. Since SBJson is widely bundled by other popular libraries I renamed all the classes & enums to make sure it can be used in conjunction with prior versions.
However, I'm not sure how to best handle this situation with CocoaPods. I contributed a 4.0.0 spec to the existing SBJson specs, but I suspect it will be impossible to install version 3.2 and 4.0.0 in the same project. Do I have to clone the 4.0.0 spec into a SBJson4 (notice extra major version number in name) spec as well?
Morning.
If you want users to have both versions installed simultaneously they will probably have to be separate pods.
AFAIK you can't have one pod installed twice in a project. I don't even know how you'd get round the linker errors etc. for that to be possible!
Our development team has been fairly small and, until now, all working on a single Visual Studio 2012 solution. We are growing and wanting to create better separation with multiple solutions for different project teams.
However, there are occasions where the code in one solution will want to utilize code from another. We have decided using internal (i.e. private) NuGet packages will be a good way to manage these dependencies.
However, the question has come up on how to deal with multiple versions of the same package that are in different SDLC stages (e.g. Development, QA, Staging, Production, etc.)
Example: If we have these three solutions...
CoreStuff
CoolProject1
CoolProject2
If working in CoolProject1, and we need to utilize code from CoreStuff, we can add the NuGet package. Presumably this package will be the latest Production (stable) version of CoreStuff.
However, what if a developer working on CoolProject2 is aware of some changes in CoreStuff that are currently in Development and wants to utilize that version?
Not sure if the best approach is to create separate packages for each (seems to require changing your package references back and forth depending on what stage the solution is in) or somehow utilize multiple versions of the same package (not sure if that's easy to manage with NuGet).
Anyone tackle something like this?
The first thing to remember is that NuGet will not automatically update your package references, so if you have already 'linked' your solution to the latest stable package of CoreStuff (say 1.2.2) then there won't be any problems if a newer (unstable) version is provided (assuming that the package you're using doesn't disappear from the package repository). Obviously if you upgrade your package reference then you will get the unstable package.
So the simplest solution is to make sure that you 'link' your project to the stable package by getting it via the NuGet package manager before the other package is released. While the UI only allows you to get the latest version, the Package Manager Console can get any version of a package so you could use that to explicitly provide the version number, e.g.:
Install-Package CoreStuff -Version 1.2.2 -Project CoolProject1
If that is not a solution then there are several other options to tackle this problem:
Give the development version a different semantic version that indicates it is a unstable version, e.g. 1.2.3-alpha. In this case CoolProject1 could pull in package CoreStuff.1.2.2 (which should be latest stable version in your repository) and CoolProject2 could pull in CoreStuff.1.2.3-alpha (which would be the latest unstable version).
Have multiple repositories, e.g. one for stable (released) packages and one for unstable (development) versions. Then you can select your packages from the desired repositories. If you wanted to you could make it so that only your release process can push packages up to the stable repository and your CI build pushes up to the unstable one (so that you always have the latest packages available)
If the developer of CoolProject2 just wants to develop against the latest version (but will wait to release CoolProject2 until after CoreStuff v.next has been released) then he could potentially create a local package repository (i.e. a directory on his drive) and put the new package of core stuff there. That way other developers won't even see the package.
The most important thing will be to make sure that you don't get CoreStuff.1.2.2 and CoreStuff.v-next in the same repository if CoreStuff.v-next simply has a higher version number, because in that case the NuGet UI won't let you pick v1.2.2 (but the Package Manager Console does!).
If you would want to switch from one package type to another you'd have to do a manual update (which you always have to do when changing to the next package version anyway), but that's not a bad thing given that this forces a developer to at least check that the update of the package doesn't break anything.
I've been trying to build the 3.2.2 and 3.2.3 tags of WSO2 Carbon from here using Maven 2:
https://wso2.org/repos/wso2/tags/carbon/3.2.2
https://wso2.org/repos/wso2/tags/carbon/3.2.3
However, the Maven pom.xml files throughout the directory trees beneath these tags still refer to version 3.2.0 in both cases - am I missing something obvious please?
When I try and analyse the results of both the builds using our in-house tool I get identical results in the two cases (and indeed results that are identical to those for 3.2.0), which makes me think I may be building 3.2.0 repeatedly by accident.
3.2.2 and 3.2.3 are point releases and typically involves bug fixes/optimizations that do not introduce new features to the 3.2.0 release. If a particular component do not have any fixes/changes, the version still be the older version, no new version is introduced. This is how the versions are handled.
You're not missing anything. It seems they did screw up. Maybe that was their intention, but then it doesn't make any sense at all (at least for me).