Lets assume that we have a project Foo which defines its contract. I've developed it on branch X and published stub jar to maven snapshots repository with version 0.0.1-X-SNAPSHOT.
After all I released it with version 0.0.1 and published to maven released repository.
Then I wanted use it on my other consumer service so I configured stubrunner in given way:
stubrunner:
repository-root: http://myreleased.repo,http://mysnapshot.repo
work-offline: false
The problem is that in that case the latest resolved version is 0.0.1-X-SNAPSHOT not 0.0.1 as I expected to be as I want released to take precedence over snapshot.
Any suggestion how to fix that? The simplest solution of course is to remove snapshot repository from list or repository-root but are there any other?
Thanks in advance
The problem is that in that case the latest resolved version is 0.0.1-X-SNAPSHOT not 0.0.1 as I expected to be as I want released to take precedence over snapshot.
I think it takes timestamp into account. AFAIR you could change the + in the version to latest.release. And if that doesn't work then you'd have to run the test twice with different repo roots.
Related
I have built a NuGet Package and uploaded it to a locally hosted Sonatype Nexus repository.
I have given it the version 0.1.1+251019-020007-e3baff. My understanding of sem-ver 2.0 is this should be treated as a stable/release version (because the data after the + should only be treated as metadata), but nuget seems to be getting confused and showing it only if I include prerelease versions in the search.
For example in the cli if I run Find-package <my-package-name> I get no results. But if I run Find-Package -prerelease <my-package-name> I get
Id Versions Description
-- -------- -----------
<my-package> {0.1.1} <description>
Likewise if I use the GUI in Visual Studio I have to check the "include prerelease" option, but then the version that is available is marked as "latest stable"...
In Nexus there is a flag "is_prerelease" that is being set to true by something, not sure what, Is that flag being incorrectly set and then being used in the search?
Is there something else I am doing wrong? Is my understanding of the + character in sem-ver 2.0 not correct?
I am using NuGet version 4.9.3, and nexus is version 3.19.0-01
NuGet's logic is available as packages, the versioning logic in the NuGet.Versioning package. Using this little program:
static void Main(string[] args)
{
var version = NuGetVersion.Parse("0.1.1+251019-020007-e3baff");
Console.WriteLine($"Version is prerelease: {version.IsPrerelease}");
}
I get the output
Version is prerelease: False
I tried many versions of the NuGet.Versioning package, from the latest 5.3.1, to 4.9.4, 4.3.0, 3.5.0, 3.2.0 and even the oldest release version of the package, 1.0.1. All of them say that your version is not prerelease.
Therefore, it's not NuGet that thinks your package is prerelease. Given that - is the separator for prerelease labels, my guess is that Nexus is incorrectly doing a simple check similar to version.Contains('-') to determine if it's pre-release. This is a shame, as semver.org has two regex expressions on their website which do not have this behaviour (example, I have no idea how long this link will be valid). If your Nexus installation isn't running the latest version, I suggest trying to update if you can. If it's still a problem, you could try contacting the software vendor to report a bug.
As a work around, you could try avoid using the - character in the build metadata as long as you keep using Nexus. SemVer2 is quite restricted in the characters it lets you use, so I suggest using . instead (0.1.1+251019.020007.e3baff).
maybe someone has a good idea for the following scenario:
I have
prerelease dev packages, like that: packagename.1.2.0.1000-dev.nupkg
and
release packages, like packagename.1.2.0.1.nupkg
My idea was: starting at a higher number range for the dev packages would always allow getting the dev packages for developers if they enable the Pre-Release option at the nuget update step. This works fine.
Then later on I would like to update the project to the latest release version. But it seems there is no option to update to the latest release version that has a lower version number than the dev/pre-release package? Also the -Safe option doesn't seem to work here.
I can't keep the build numbers in sync also since these are different builds. If I have it the other way around, so higher build numbers for the release versions, it would never update to the latest dev packages if I do a normal nuget update, even including the pre-release packages...
Any idea here?
Thanks a lot!
Any package that is publicly available is a "release package" in technical/English terms. But the software industry has bastardized the language. So lets talk about stable (no prererelease tag) and unstable releases (prerelease tag).
The publisher history should be something like this:
1.0.0 // First **stable release**
1.0.1-alpha // First **unstable release** Candidate bug fix.
1.0.1-beta // 1.0.1-alpha with a tweak to the code.
1.0.1 // Second **stable release**
If the publisher follows that pattern, then end-user clients can safely pull stable release bug fixes while developers can also pull unstable prereleases at their discretion.
You can also have something like:
1.0.0 // First **stable release**
1.0.1-a.dev.1 // Next CI build after 1.0.0
1.0.1-a.dev.2 // Etc...
1.0.1-alpha // Relabeled 1.0.1-a.dev.2.
1.0.1-beta // Relabeled 1.0.1-alpha, wider audience than -alpha.
1.0.1 // Second **stable release**
It's a good practice to have separate feeds for internal dev/test, public prerelease and public stable releases.
I think I am missing something, but I want to add library from github to Android, I don't see anywhere on the Github page the latest built version of the library so I can include it in my gradle file. I have to go to maven or jetpack manually and search for it. Is there a shortcut? Am I missing something?
Thanks
There is a Lint check which allow Android Studio to query the latest versions available.
First you will have to activate this Lint Check
Go to Settings, then Editor > Inspections and search for Newer Library Version Available and check it.
Then run a code Analyze with Analyze > Run Inspection by Name... and type newer and select Newer Library Version Available
Run the inspection on the wanted scope (module only, full project, etc...)
Then you will see which library has a new version available.
PS
As stated by the Lint description of this feature, you should not let this check activated because it may slow your code analysis (query the repositories can take time)
You can use the + annotation to get a dynamic version. It can be use for the major, minor and patch part of the version. Ex :
// Major
compile group: 'org.mockito', name: 'mockito-core', version: '+'
// Minor
compile group: 'org.mockito', name: 'mockito-core', version: '2.+'
// Patch
compile group: 'org.mockito', name: 'mockito-core', version: '2.18.+'
But it's not a good practice to use such a dependency resolution.
Dependencies can unexpectedly introduce behavior changes to your app. Read your changelogs carefully!
The same source built on two different machines can differ. How many times have you said "but it works on my machine?"
Similarly, builds built on the same machine but at different times can differ. I've wasted so much time on builds that worked one minute
then broke the next.
Past builds cannot be reproduced perfectly. This makes it difficult to revert safely.
There are security implications if a bad actor introduces a malicious version of a dependency.
I found a similar issue but couldn't understand any action to take. I have two open-source scala libraries - I published the second one just yesterday. Everything looks good on the Bintray repo, but only one version makes it to jCenter.
https://dl.bintray.com/ticofab/maven/io/ticofab/ :
aws-request-signer_2.10/
aws-request-signer_2.11/
aws-request-signer_2.12/ <-- latest scala version, missing later
reactive-kraken_2.11/
reactive-kraken_2.12/ <-- latest scala version, missing later
http://jcenter.bintray.com/io/ticofab/ :
aws-request-signer_2.11/
reactive-kraken_2.11/
Is there a way I can solve this? Thanks.
Thank you for your submitting this issue.
We have managed to resolve the issue you were experiencing. The issue occurred due to a bad link to JCenter.
Usually in order to add packages to JCenter, we add only packages under 'groupID/groupID/artifactID'. Since Scala packages are different and they contain versions of their own we needed to change the link to groupID only without artifactID (groupID/groupID. i.e /io/ticofab).
This means that all artifactIDs (reactive-kraken_2.11, reactive-kraken_2.12, aws-request-signer_2.10, aws-request-signer_2.11, aws-request-signer_2.12) are now approved and synced to JCenter.
We hope this clarifies. Please let us know if you encounter any other issues.
Best Regards,
Yonatan Brand
JFrog Support
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