We use semantic versioning. Suppose we have some software release with a version number of e.g. 2.1.1. Because of an API change the next release has version number 3.0.0. Now let us suppose that a bug is found which occurs both in version 2.1.1 and version 3.0.0. Since some customers still use 2.1.1 and we do not want to force them to upgrade to a version 3.0.1 or later we provide a maintainance (bug fix) release for version 2.1.1. A straight forward version number for this release could be 2.1.2. Though no such example is given in the defintion of precedence I would conclude that the rules imply 2.1.2 < 3.0.0 - meaning what? Version 2.1.2 was released after 3.0.0 and version 3.0.0 does not include all bug fixes of 2.1.2. Actually these two versions are not really orderable, the versions (and the corresponding source revisions) now have a tree structure:
|
2.1.1 (1)
|\
| \
| 2.1.2 (3)
|
3.0.0 (2)
|
To reflect that tree structure and avoid confusion I would prefer a version number scheme like the following:
|
2.1.1 (1)
|\
| \
| 2.1.1+m (3)
|
3.0.0 (2)
|
(+m for maintainance release). According to the definition of precedence in semantic versioning this would still imply 2.1.1+m < 3.0.0, but for our customers we could add a rule that for x1.y1.z1 < x2.y2.z2 any version x1.y1.z1+m* is not comparable to x2.y2.z2 (but x1.y1.z1 < x2.y2.z2+m* still holds).
Are there any best practices for versioning a tree structure? Or did I get something wrong about semantic versioning?
No, you should not assume any release date ordering from semver precedence relations such as 2.1.2 < 3.0.0. All you can determine is that there probably have been be breaking changes between them.
If you want build date information, that would be reasonable to include in the build metadata, but that metadata has absolutely nothing to do with the semver concept of precedence. However a human might reasonably conclude that version 2.1.2+201706010005 was probably built after 3.0.0+201603151112.
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.
I have mamba 0.27 installed on my mac OS.
How can I upgrade to mamba 1.x?
Can I simply do a fresh re-installation of the newer version, if I want to keep my existing mamba environments and settings?
I checked mamba's documentation, and I searched in internet, but could not find any "how to upgrade" information.
thanks!
Mamba is like any other package in a Conda environment and can be updated like:
mamba update -n base mamba
If that doesn't update (perhaps due to needing dependencies updated), another option is to use a minimum version:
mamba install -n base 'mamba>=1'
Please note the use of quotations to avoid the > being interpreted writing to a file called "=1".
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
We are moving our code from CVS to ClearCase in order to consolidate our history in only one vcs system following the guidelines provided here http://www.ibm.com/developerworks/forums/message.jspa?messageID=13728313.
At first glance everything looked fine. All versions of all files appear to have been migrated, all branches and tags from CVS exist in ClearCase.
However not all files have branches created correctly (in my opinion). The example file.bat
has the following history (hope the ascii drawing is understandable).
1.1
1.2 --- SOME_TAG
1.3 --- SOME_OTHER_TAG
|---- BRANCH_1
1.4 --- BRANCH_2
|- 1.4.2.1
|- 1.4.2.2
Now, both SOME_TAG and SOME_OTHER_TAG is created and applied correctly in ClearCase. BRANCH_2 is created from CVS version 1.4 with version 0 on the branch having the same creation date/time as the CVS version 1.4. Which is good. Version 1.4.2.1 and 1.4.2.2 is created as version 1 and 2 respectively on BRANCH_2.
The problem is BRANCH_1 which is not created. As a minimum I would have liked to have the branch possibly only with version 0 on it.
I can see from the output of clearexport_cvs that the issue stems from here. The BRANCH_1 tag is not included in the output from clearexport_cvs command, only SOME_OTHER_TAG.
Any good ideas as how to rectify this? I couldn't find any options or switches on the clearexport_cvs command which seemed to help me.
It is important that we keep the original timestamp from CVS in order to be able to get the correct sourcecode for old builds. We used Parabuild so the only reference to CVS we have per build is similar to this "cvs update -P -A -d -D "2012-12-20 13:31:42 GMT" -r BRANCH_1"
Kind regards
Peter
If the clearexport_cvs doesn't work completely, and since there is no way to export only one branch, It is best to try fixing the import incrementally, and do a clearfsimport on a a dedicated ClearCase branch.
That would allow you to "patch" the history import with a few selected revisions from the CVS repo, but this isn't an automated process (unless you script the update of a CVS workspace, a bit like I did for Subversion).
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.