I'm collaborating on a vscode extension that uses a native module (#serialport) which needs to be included / pre-compiled for each platform/electron-version combination.
if we only include the current versions, it frequently breaks when vscode updates the electron version. some platforms can nativly re-compile , other can only after a (very) lengthy install of rather-complex toolchains that IMO should not be required for end-users.
So we want to include the relevant prebuilds,
and for that we need to look ahead in time ...
I'm looking for a reliable method to determine the electron versions used by vscode
- current version
- and the future (insider) version
- in addition it may be good to include a prior version to allow for backward compatibility
I have found that master/.yarnrc has the current ( or next imminent) version
today it is 4.2.7
vscode current release uses 4.2.5
prior versions can be read from the version history
master/.yarnrc
but what about the future / insider version ?
what is a good method/location to determine that programmatically ?, i.e. Which branch has the insiders version ?
Probable answer based on below hints and some more probing :
next version is in master ..microsoft/vscode/blob/.yarnrc
version 1.36.1 is in ..microsoft/vscode/blob/1.36.1/.yarnrc
version x.y.z is in ..microsoft/vscode/blob/x.y.z/.yarnrc
which only leaves the in-between versions/tags to be discovered.
intended approach:
during the build collect the relevant electron versions, ie "3.1.8","4.2.5","6.0.0-beta.0"
determine the ABI used by these versions using node-abi
var getAbi = require('node-abi').getAbi;getAbi('$version','electron')
use prebuild-install to download the relevant native prebuilds bindings, and include these as part of the extension
.\node_modules\.bin\prebuild-install.cmd --runtime electron --target $version --arch $arch --platform $platform --tag-prefix #serialport/bindings#
copy the bindings files for all ABI-arch-platform combinations to a folder, and inclide that in the vscode extension package
at load time , determine the ABI version of the running instance of vscode/electron, and dynamically load the module from the ABI/platform folder
alternative / additional approach:
- as a last ditch effort the code could try a just-in-time download of the pre-build binding file for the current platform, but this might run into permissions/malware scanner problems as that is essentially downloading downloading executable code from an external github repro.
current script code to download the bindings:
https://github.com/Josverl/pymakr-vsc/blob/fix/SerialMultiPlatform/scripts/mp-download.ps1
okay, so reverse logic then indicates that:
next version is in master https://raw.githubusercontent.com/microsoft/vscode/master/.yarnrc
version 1.36.1 is in https://raw.githubusercontent.com/microsoft/vscode/1.36.1/.yarnrc
version x.y.z is in https://raw.githubusercontent.com/microsoft/vscode/x.y.z/.yarnrc
which only leaves the in-between versions/tags to be discovered.
Related
I am trying to figure out what "version": 1 or "version": 2 at the end of a Package.resolved file generated by Swift Package Manager stands for. I have two workspaces and sometimes the Package.resolved files have both version 1 or 2, sometimes different versions.
What kind of impact has having different versions and what is causing the version change? Is it possible to have the same versions for both?
I've done a bit of research and it seems Apple changed the format of the Package.resolved file with version 5.6 of the Swift tools. Any version of the toolchain can work with version 1 but you need >= 5.6 to work with version 2. See this forum conversation
https://forums.swift.org/t/using-swiftpm-5-6-and-supporting-older-versions/55708/9
As I said in my comment, it's probably best to ignore what's in that file and not commit it to your source code control. One of the comments in the above forum thread mentions that you might want to commit it to ensure repeatability of builds, but that is a fragile solution and if you want to build with exact versions, you should do this in the Package.swift file.
Addendum
You'll get mixed versions because, if resolving a package means no changes, spm will not overwrite the old Package.resolved.
I want to install a previous, specific version of k8slens (https://k8slens.dev/) but impossible for me to find this (neither for mac nor windows !) Do I have to download the source code and rebuild it? Even with this there is no "install" section in the makefile !
Why is it so difficult to find a specific version?
Yes, you can easily download the source code for a specific version tag and the compile and use it. The list of tags is here.
Once you get the source code of your desired version you can generate the binary with :
make build
And then simply run that binary to get your required version. Just know that install simply means copying a compiled binary in a known Path of the system so it can be executed. There is nothing special about it.
The question was made some time ago but just in case you haven't reached the answer yet, One thing I did to solve this problem was that i went to the lens repo : https://github.com/lensapp/lens/releases and search through the old release versions seeking for a binary asset (.exe) (the news version provide the source code but not the binary) then i managed to find the binary of the version 4.2.3. ( release in Apr 26, 2021)
Worked perfectly for me. Hope it helps
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).
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 am wondering how can I ensure that my bower version configuration will be workable in the future?
E.g. I have already touched multiple projects, which either tell to use
">=1.0.0"
"~1.0.0"
Afaik the
">=" tells that all versions above 1.0.0 are fine
"~" tells all versions/minor updates on 1.0.x are fine
To be more specific:
"dependencies": {
"angular": ">=1.3.0",
"bootstrap": ">=3.2.0",
"jquery": "~2.1.0",
}
Of the day of writing this code following version configuration was included:
angular: 1.3.1
bootstrap: 3.2.0
jquery: 2.1.0
today you will get included:
angular: 1.4.0
bootstrap: 3.3.4
jquery: 2.1.4
From the point of the developers integration of the lib this features are fine on the beginning of the development. You have not to mess around with the painful dependency management of the libs and versions. But as soon as it gets tested the version should be fixed to defined versions.
I have already touched multiple projects which got broken after a very short period of 3 months, since the libs got updated to different versions, which either are incompatible to each other or some features got broken. So either the build was not working any more or even more bad, issues arise on client side.
What is the best practise to get rid of such version issues on the long term projects?
At the moment there is none, if your only option is bower. A lockfile a la composer or a shrinkwrap mechanism a la npm is in the works however it seems to have stalled as there are currently not enough contributors/maintainers to test the feature and maintain it in the long run.
UPDATE:
Since we now have yarn you can opt to use that, which uses a lockfile mechanism as the default behaviour. The only caveat is that it uses the npm registry which means that either some packages haven't been registered there yet, or have been namespaced like Google's Polymer which you might have to watch out for.
My get-t-go method is using exact versions,
don't let your dependency tool decide what version is best for you because they (and other people) are usually wrong.
What I mean by that is, and I have seen this plenty enough on bower. That one day you get version A.B.C and the next day you might get A.D.F and A.D.F conflicts with some other dependency you have. This can introduce all sort's of problems.
Best is to do handle all your upgrades yourself and test this yourself.
I have yet to see a project where UI and javascript testing was automated in such a way that this was done reliably.