Ref:
Nuget Versioning
SemVer
The nuget versioning documentation reads:
SemVer also introduces the concept of a build number for those creating daily or continous builds. This is not supported in the public NuGet.org gallery.
It says it's not supported in nuget.org gallery but i'm wondering specifically how nuget.exe -update or -install or the Package Console in VS handles it...
Take a look at SemanticVersion.cs in the Nuget codebase. This provides the following regex to validate the provided version. If the regex doesn't match, the version is invalid:
new Regex(#"^(?<Version>\d+(\s*\.\s*\d+){0,3})(?<Release>-[a-z][0-9a-z-]*)?$",
RegexOptions.Compiled
| RegexOptions.IgnoreCase
| RegexOptions.ExplicitCapture);
The format for the prerelease string strictly has to start with a dash, then a letter, then any combination of dashes and alphanumerics. No + or . allowed.
Try and pack with anything other than a valid version and you will get:
Attempting to build package from 'ConsoleApplication1.csproj.nuspec'.
'1.0.1+421.500' is not a valid version string.
Parameter name: version
If you've somehow got a package with an invalid version, then the nuget packaging process must have been bypassed and I can only assume attempting to push it will have unpredictable results.
Related
I'm trying to make a debian package of Apache-Age and it can successfully build either with
"postgresql-server-dev-11"
or
"postgresql-12"
I've made my control file in the following way :
Source: age
Section: database
Priority: optional
Maintainer: unknown <sarthak#SARTHAK>
Build-Depends: debhelper-compat (= 13),
postgresql-12,
build-essential,
libreadline-dev,
zlib1g-dev,
flex,
bison
Standards-Version: 4.5.1
Homepage: <insert the upstream URL, if relevant>
#Vcs-Browser: https://salsa.debian.org/debian/age
#Vcs-Git: https://salsa.debian.org/debian/age.git
Rules-Requires-Root: no
Package: age
Architecture: all
Depends: postgresql-12
${misc:Depends},
${shlibs:Depends}
Description: Apache AGE is an extension for PostgreSQL that enables users to leverage a graph database
on top of the existing relational databases.
Here it's only for postgresql-12, but how can we specify postgresql-server-dev-11 also in the dependency field so that if any of the two version is present the build can proceed without errors.
Normally extension are server dependent, you need to build two different package for two different PG version (from two separate branches)
So I figured it out, it's quiet simple, if we want to specify multiple versions of a driver in 'OR' fashion, like if either of the versions is present in the system, the dependency check should pass,
by simple using bitwise 'OR' operator, like this :
Build-Depends:
debhelper-compat (= 13),
postgresql-11 | postgresql-12,
build-essential,
So here if any of the postgresql version 11 or 12 is installed, the deb file will continue with the installation.
According to this article https://py-pkgs.org/07-releasing-versioning.html, versions in pyproject.toml follow the semantic versioning standarts.
So my file looks like :
[tool.poetry]
name = "my_project"
version = "0.1.0"
description = "..."
...
Wanting to build a pre-release, I wrote 0.1.0-1 as version number.
That should be allowed according to https://semver.org/
But my build is rejected and I have to set 0.1.0.1, which doesn't fit standarts.
Is it a misconfiguration of my Jenkins project or another third party tool, or 0.1.0.1 is indeed the intended way to write versions
The following command used to work flawlessly:
C:\tools\apache-cxf-3.3.1\bin\wsdl2java -client -d generated foo.wsdl
It no longer works with the latest version of JDK - 12. I have downloaded the latest version of Apache CXF, and still get the same error:
-Djava.endorsed.dirs=C:\tools\apache-cxf-3.3.1\bin\..\lib\endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Could anyone offer a tip on how to remedy this?
I got the Apache CXF 3.3.1 wsdl2java utility to work with the latest OpenJDK 11 by doing 4 things:
Pull down this jar and place it into the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.jws/jsr181-api/1.0-MR1
Pull down this jar and also place it in the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.xml.ws/jaxws-api/2.3.1
In my case, since I'm running on a Mac, I vi'd the wsdl2java script and made sure these two jars are explicitly being set on the CXF classpath, by doing the following declaration within the script right before the execution of the java command:cxf_classpath=${cxf_classpath}:../lib/jaxws-api-2.3.1.jar:../lib/jsr181-api-1.0-MR1.jar
Lastly, I removed the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' parameter from the java command at the end of the script, since newer JDKs no longer support this argument, so my command now looks like this:$JAVA_HOME/bin/java -Xmx${JAVA_MAX_MEM} -cp "${cxf_classpath}" -Djava.util.logging.config.file=$log_config org.apache.cxf.tools.wsdlto.WSDLToJava "$#"
Now, using OpenJDK11, I'm able to point to an external WSDL file and successfully generate the client code I need to consume this SOAP service with the following command:
./wsdl2java -client -d src https://somewhere.com/service\?wsdl
Whether or not this all works yet is TBD in terms of being able to call and consume the SOAP service I'm coding against, but I've at least now overcome the Java9+ support issue with this tool specific to generating client code from a WSDL.
If your needs are different, I would at least remove the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' JVM parameter and start calling the wsd2java command with the parameters you need set and just start iteratively adding back in the missing libs it starts throwing java.lang.NoClassDefFoundError errors for.
Their FAQ specifically says starting in 3.3.x, Java 9+ will be supported but something clearly dropped the ball between the no-longer-supported hardcoded JVM arguments still being passed in the utility and the missing libraries to support the newer JDKs where these legacy libs have been removed.
Hope this helps someone out there unfortunate enough to ALSO still be programming against SOAP endpoints but trying to at least keep the client-side code you're writing up to date and taking advantage of the newer features of the modern JDK.
With a .NET Framework library you could specify a version with a wildcard and NUGET pack command would append the build date and version automatically when running a NUGET Build Task in VSTS.
[assembly: AssemblyVersion("1.0.*")]
NUGET PACK would generate a NUPKG file with a version like 1.0.6604.1234 appending the date number and a build ID.
NET Standard issues
In .NET Core and .NET standard the new .csproj format does not support this wildcard format.
We can't package with Nuget.exe (reason: this issue) but we can use dotnet pack except I need to auto-increment the build numbers. The dotnet Build Task in VSTS allows me to wholly replace the version number, but I want to retain the version in the csproj file, and just append a build number (as I used to).
I found that using <VersionPrefix>x.y</VersionPrefix> in the csproj file would work with nuget pack and I could then add the additional parameter VersionSuffix=$(Build.BuildNumber) to the pack task.
All looked good until the first dev updated the project version in the project properties dialog. Visual Studio ignored the VersionPrefix and set the <Version> tag - and the build number fix is ignored because a Version tag exists.
Is there a way to read the Version from the csproj? If so I could set the build property to Version=$(ProjectVersion).$(Build.BuildNumber) ?
Or are there alternative ways to handle auto-incrementing the build version when packaging?
First you can select Use an environment variable for Automatic package versioning, use your defined variable such as temp ($(build.buildNumber)) as Environment variable.
More details take a look at this link: Dotnet pack automatic package versioning build number clarification
Another way is using the "arguments" field in the dotnet CLI task, you can pass additional arguments to the dotnet cli.
Using --version-suffix $(Build.BuildNumber) will pass the build
number as version suffix. Make sure you don't have a <version>
element set in your csproj, but rather a <versionprefix> element.
The built version will look like versionprefix-versionsuffix, so for
example, if you have <versionprefix>1.2.3</versionprefix> and build
number 201805002, the built version will be 1.2.3-201805002. In this case do not select the automatic package versioning.
Thanks to #patricklu-msft for his suggestions.
There is it appears no built-in way to emulate the wildcard behaviour we previously had NUGET pack with dotnet pack, nor was there way to get the <Version> tag out of the project file.
So I've created a new VSTS Build task that does this: VersionTaskReader in the MarketPlace.
This extension can be pointed to a .csproj or .vbproj and will set an environment variable VERSION, and VERSION_BUILD which has the BUILDID appended. You can optionally add a prefix to make each instance different if needed.
For example, if your project contains <Version>1.1</Version> then the VERSION_BUILD would be something like 1.1.8680
Then the dotnet pack task can use the environment variable VERSION_BUILD in the versioning options screen, so that the build number automatically increments.
The simple directions found all over the internet for installing Core using OPAM no longer work. What is the new way to install and use Core?
I think I tracked the problem down to a message on the ocaml-core mailing list about renaming several dependencies https://groups.google.com/forum/#!topic/ocaml-core/Te6LTiNBO08.
Paired down, the widely published installation instructions amount to two steps after installing opam itself:
$ opam install core
$ cat >> ~/.ocamlinit <<EOF
#use "topfind";;
#thread;;
#camlp4o;;
#require "core.top";;
#require "core.syntax";;
EOF
Following these directions result in an error about the "sexprlib.syntax" package missing when using ocaml (or corebuild, utop, etc).
Failing directions can be found in this widely referenced ebook
https://github.com/realworldocaml/book/wiki/Installation-Instructions#setting-up-and-using-utop
and are reflected in directions here on Stackoverflow in questions such as:
Ocaml utop library paths, Core module
What is the new way to set up Core?
opam install core no longer seems to be sufficient since it does not pull in the new syntax packages. I am not sure if this is a dependency bug or not.
The recommended ocamlinit settings also seem wrong.
I found that the core 113.24.00 is defective and all the installation instructions on the net as of this writing are out of date.
Users must make the following corrective steps:
Remove all #require references to packages ending in .syntax from ~/.ocamlinit.
Make your own corebuild script without any references to syntax packages
as found at https://github.com/janestreet/core/blob/master/corebuild.
You may also remove the #camlp4o;; line from your .ocamlinit as this library is no longer required by Core.