I understand that using ^2.x and ^2.1.2 will both update minor versions and patches as long as major version is still 2, however should I specify minor version and/or patch version if I use the caret?
One of the comments in https://bytearcher.com/articles/semver-explained-why-theres-a-caret-in-my-package-json/ says:
you don't actually want 2.., because that allows both newer and older releases. ^2.1.2 means "2.1.2 or newer".
But if I know ^2.1.2 is already released, wouldn't using ^2.x essentially always be equivalent to ^2.1.2, so is there a purpose to including minor and patch version?
Use this tool to test your hypotheses: https://semver.npmjs.com/
According to this tool, there is a point in including the minor and/or patch version. After experimenting a little bit, it seems that the caret symbol will lock down the minor version but it won't pull in anything that is older than the version you supplied.
So for example: ^2 can pull in version 2.2 but ^2.3 will not.
Related
Bearing in mind that
100 > 9
and
.9 > .100
Which of these is the later version?
Version 2.1.100
Version 2.1.9
I'm trying to figure out whether the dots in a version label act as a decimal point or if they are simply delimiters around independently incrementing numbers.
The common practice seems to have 2.1.9 is before 2.1.100. See for instance
Semantic versioning
Debian version comparison algorithm
RPM version comparison algorithm
but people tends to do their own thing, especially when considering old enough software (the RPM documentation reference hints that Perl version had such oddity in the past, probably related to the presence of initial 0 in a segment)
Allen NLP 0.9.0 (and maybe later) had a pruner module - intended to score and prune spans (https://docs.allennlp.org/v0.9.0/api/allennlp.modules.pruner.html). This seems to have gone missing, I cannot find it in the latest release, or the allennlp-models repo. Is it still part of the library - if not I have the original code so it's no big deal but if it was removed what was the reasoning?
I’m having a problem with printing figures in octave when the figure’s visibility is set to false. For example, the following code produces a “panic: segmentation fault” in Octave version 4.2.2:
t = 1:10;
fh = figure(“visible”, false);
plot(t,sin(t))
print(“fig.png”)
If I run the above code in Octave version 5.2.0, there is no problem. Is this a bug that was fixed in the Octave 5 update? If so, is there a workaround that I can use for Octave 4? I would prefer to use Octave 4 if possible.
Other notes:
I am running this in Ubuntu 16.04.6 LTS and I installed octave 4 using apt.
The answer to your question is, yes. Here is the relevant line from the v5.1.0 NEWS:
Dependencies:
The GUI requires Qt libraries. The minimum Qt4 version supported is Qt4.8. Qt5 of any version is preferred.
The OSMesa library is no longer used. To print invisible figures when using OpenGL graphics, the Qt QOFFSCREENSURFACE feature must be available and you must use the qt graphics toolkit.
Apparently the now deprecated OSMESA dependency and the printing of invisible figures was a long-standing pain-in-the-butt. Maybe you'll have some luck going through bug comments (e.g. someone says that if you make it visible at least once, it may be possible to print).
But as people have said in the comments, the best thing to do would be to upgrade your octave version, and recompile your mexfiles for the new version.
I currently have 1.23.1 installed and would like to update to ´1.30´ and got bunch of extensions installed. What would be the best way to update the wiki? Should I update version by version or jump straight the the final version that I want?
There is no real benefit in updating version by version; the upgrade script just applies DB schema changes from each version successively, so mostly the result will be the same both ways. If something breaks, going step by step and testing after each step will tell you which version broke it, and thus you are in a better position fixing/reporting it, but it's usually not too hard to figure that out anyway and it would be a vast time sink.
I am using bower currently as well as an Angular. One of the plugins I am using (ngTable) has a dependency ~1.2.9
Currently am getting confused one what this actually means.
If I set angular as =1.2.14 this still runs fine but in the output of the command line it mentions 1.2.9 angular as well as .14
Some clarity on this would be greatly appreciated.
My current understand (which may be wrong) is that
= (Means that it will always be that)
> (Means putting 1.2 will allow for the highest of 1.2 until 1.3)
=> (Means equal or more same as above)
But when it comes to >1.2.9 or ~1.2.9 I'm not sure
~1.2.9 means the last patch version starting from 1.2.9.
Update:
So 1.2.9, 1.2.10, 1.2.11... but not 1.3
>1.2.9 means the version must be greater than 1.2.9. 1.3 is OK.
More information on the syntax for dependencies is available on npm site