Is there a file which ties the libversion to the release number. The libversion is in a file in the release, but I can't find documentation to trace this back. Working with a version of Linux that has one libversion of Poco and a SDK that was released was a different libversion and I am trying to track down the releases. Thanks.
I figured I go ahead and try to get and answer on Git Hub. There is no master file/database with the numbers , but it isn't super difficult to find. If you go to the tagged version (eg 1.11.0) and look at libversion - the number will be 81. Go back to tag version 1.6.1 and the libversion and the number is 31. I was able to create the database of the versions I needed based on trial and error.
When you initialize Firebase hosting, it includes a comment in the header of the index.html file that is generated:
<!-- update the version number as needed -->
<script defer src="/__/firebase/7.5.2/firebase-app.js"></script>
My question has to do with "as needed;" I looked at the docs, and didn't see an explanation.
Probably this means it is supposed to be obvious -- but when you're a beginner, most things aren't!
So, to make my question more concrete:
When might updating the version make a Firebase web app break?
Relatedly, if an app is working, and one does not update for a long
time (many versions/years), does the app remain functioning? Or will it break if not kept current?
Does "as needed" imply "as needed [for access to new features]"?
Finally, is it implied that these changes should be implemented
manually -- by regularly looking up what the latest Firebase version
is, and typing a new version number in index.html -- or is there some
kind of automatic "stay current" workflow/tooling/convention that is
implied?
I realize that there are a number of sub-questions above, but they are all intended to be clarifications of "update as needed," so I think they belong in the same place.
I hope any answers will help other beginners understand the larger issue of when it is appropriate to update the services an app depends upon! Thanks.
Firebase follows what is known as semantic versioning (SemVer) rules.
From semver.org:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
That means that the API is guaranteed to stay compatible within minor version (7.x) in your case, but breaking changes may be made in major version (8.0). This means that minor versions (7.x) are used to fix problems, and sometimes add minor features that don't break existing behavior.
With that knowledge, let's see if we can answer your questions:
When might updating the version make a Firebase web app break?
Updating within the same major version (7.x, e.g. 7.5.2 -> 7.5.3, or 7.5.2 -> 7.6.0) should not break your app. There are some exceptions, such as when your code depends on buggy behavior that was fixed, or when there is a mistake in the release. The latter will typically be fixed by the Firebase team as soon as possible, while you'll typically want to roll back to the previous version and update your code in the former case.
Relatedly, if an app is working, and one does not update for a long time (many versions/years), does the app remain functioning? Or will it break if not kept current?
Once a version is published, it remains unmodified. So your app will stay working the way it did when you made it.
Does "as needed" imply "as needed [for access to new features]"?
Two main reasons for upgrading:
To get access to new features.
This is the most obvious reason to upgrade, as it allows you to add new functionality from Firebase to your app. Most often this
To get access to bug fixes.
Bugs may be discovered in the library version you use, and some of those bugs may be security holes. In that case, not updating to a more recent version means that you'll have a known security vulnerability in your app. Key to realize here is the known part: most hackers search for apps with known vulnerabilities, instead of trying to find new vulnerabilities.
Finally, is it implied that these changes should be implemented manually -- by regularly looking up what the latest Firebase version is, and typing a new version number in index.html -- or is there some kind of automatic "stay current" workflow/tooling/convention that is implied?
If you use a tool to build/pack your website, that typically has a way to automatically pull in new versions.
Many developers configure such a tool to automatically pull in new patches (7.5.x) upon every build, while some even pull in new minor release (7.x.x). But there's also a school of thought that prefers to hard-code the exact version number and only upgrade manually by regularly checking.
Either way, it's required to make a new build to upgrade, even in this case. That's a Good Thing™️, as the last thing you want is that your app breaks in production when Firebase accidentally releases a new version with a bug (a rare occurrence, but it has happened). By only including a new version in your build process, you reduce this risk, especially if you run automated tests of your app's functionality as part of the build.
There's no right or wrong answer here, as either can work just fine. It's really up to your own preference.
today we received info from one of our customer about this malware detection:
Gen:Variant.Adware.Kazy.795337
It's only inside the qwebp.dll file attached to our project by qtdeploy process.
We're building 32-bit Qt (5.13.2.0) from the source and the same issue is reported on the same DLL no matter where it was built. We're using the latest VS 2019.
https://www.virustotal.com/gui/file/9f09c05803ad4ffcd99454c420a840e17549ee711690fb1f11fd1b59bccc3b23/detection
https://www.virustotal.com/gui/file/80c4c747d781a27c72de71c0900ccc045aefd2b4e4f17c949aaeeb3d0b7973b1/detection
When I scanned the older version (5.13.0.0) everything is ok:
Previous versions seem to be clean:
https://www.virustotal.com/gui/file/b7b7cacaef0e76439ef8c367c401524e93dfa00c9ca67a20290e829fec325a5a/detection
Also, any debug build and 64-bit builds are clean too.
Any idea what can cause this? Can anyone else please try to scan this file?
Thanks
TL;DR: It is probably nothing, but notify Qt anyway (and check your own systems).
Are you using the prebuilt Qt binaries or are you compiling the sources yourself?
If you are using the official prebuilt binaries, I'd of course expect that the Qt Devteam scans them and verifies that they don't accidently spread malware, but there is always the miniscule chance of something slipping through.
Same goes for the sources - while their review process should be thorough enough to avoid malicious code being slipped in, there is still the outside chance of either a key account being compromised or (even more unlikely) bad code being added slice-by-slice over a longer time period to avoid detection (along the lines of the underhanded C contest). Still, either case seems to be rather unlikely.
Bottom line: while this does sound like (and probably is) a false positive, you still may want to raise an issue with Qt e.g. on the their Bugtracking site or directly with Qt support (if you have a commercial license) to be sure. Also (if you didn't do that already) verify that the problem is not on your end, e.g. that your computers are clean and that you don't just randomly catch/detect your infection in that file.
Update:
A ticket concerning this issue was opened (I assume by Ludek Vodicka) on Qt bugtracker. Opened on Nov 19th and categorized as P1: Critical, but unfortunately no indication that it is actually being worked on (at least of Dec 18th).
Do we have any cli/api to check openstack development version..i mean whether my system installed havana or grizzly.I searched the openstack cli/api docs but i don't find any relevant.
OpenStack has a number of elements if you want to verify state.
Each of the component projects and each of the python-client api bindings have their own versions. Then there are configurable options for addressing API versions in REST queries.
I took a crack at building an API for the very purpose of verifying this data as well as all python dependencies a while back with the aim of cross verifying that against a vulnerability database but I simply haven't had the time to bring it to completion.
This would be a very useful feature I think.
You might look at your pip requires if you installed from source. Alternatively you can follow the debian package version chain from dependencies and that should provide good insight into what is installed on your system though it's not exactly verified.
Assume that I set up an automatic nightly build. What artifacts of the build should I save?
For example:
Input source code
output binaries
Also, how long should I save them, and where?
Do your answers change if I do Continuous Integration?
You shouldn't save anything for the sake of saving it. you should save it because you need it (i.e., QA uses nightly builds to test). At which point, "how long to save it" becomes however long QA wants them.
i wouldn't "save" source code so much as tag/label it. I don't know what source control you're using, but tagging is trivial (performance & disk space) for any quality source control system. Once your build is tagged, unless you need binaries, there really isn't any benefit to just having them around because you can simply re-compile when necessary from source.
Most CI tools let you tag on each successful build. This can become problematic for some systems as you can easily have 100+ tags a day. For such cases I recommend still running a nightly build and only tagging that.
Here are some artifacts/information that I'm used to keep at each build:
The tag name of the snapshot you are building (tag and do a clean checkout before you build)
The build scripts themselfs or their version number (if you treat them as a separate project with its own version control)
The output of the build script: logs and final product
A snapshot of your environment:
compiler version
build tool version
libraries and dll/libs versions
database version (client & server)
ide version
script interpreter version
OS version
source control version (client and server)
versions of other tools used in the process and everything else that might influence the content of your build products. I usually do this with a script that queries all this information and logs it to a text file that should be stored with the other build artifacts.
Ask yourself this question: "if something destroys entirely my build/development environment what information would I need to create a new one so I can redo my build #6547 and end up with the exact same result I got the first time?"
Your answer is what you should keep at each build and it will be a subset or superset of the things I already mentioned.
You can store everything in your SCM (I'd recommend a separate repository), but in this case your question on how long you should keep the items looses sense. Or you should store it to zipped folders or burn a cd/dvd with the build result and artifacts. Whatever you choose, have a backup copy.
You should store them as long as you might need them. How long, will depend on your development team pace and your release cycle.
And no, I don't think it changes if you do continous integration.
This isn't a direct answer to your question, but don't forget to version control the nightly build setup itself. When the project structure changes, you may have to change the build process, which will break older builds from that point on.
In addition to the binaries as everyone else has mentioned I would recomend setting up a symbol server and a source server and making sure you get the correct information out and into those. It will aid in debugging tremendously.
We save the binaries, stripped and unstripped (so we have the exactly same binary, once with and once without debug symbols). Further we build everything twice, once with debug output enabled and once without (again, stripped and unstripped, so every build result in 4 binaries). The build is stored to a directory according to SVN revision number. That way we can always retain the source from the SVN repository by simply checking out this very revision (that way the source is archived as well).
A surprising one I learned about recently: If you're in an environment that might be audited you'll want to save all the output of your build, the script output, the compiler output, etc.
That's the only way you can verify your compiler settings, build steps, etc.
Also, how long to save them for, and where to save them?
Save them until you know that build won't be going to production, iow as long as you have the compiled bits around.
One logical place to save them is your SCM system. Another option is to use a tool that will automatically save them for you, like AnthillPro and its ilk.
We're doing something close to "embedded" development here, and I can tell you what we save:
the SVN revision number and timestamp, as well as the machine it was built on and by whom (also burned into the build binaries)
a full build log, showing whether it was a full/incremental build, any interesting (STDERR) output the data baking tools produced, a list of files compiled and any compiler warnings (this compresses very well, being text)
the actual binaries (for anywhere from 1-8 build configurations)
files produced as a side effect of linking: a linker command file, address map, and a sort of "manifest" file indicating what was burned into the final binaries (CRC and size for each), as well as the debugging database (.pdb equivalent)
We also mail out the result of running some tools over the "side-effect" files to interested users. We don't actually archive these since we can reproduce them later, but these reports include:
total and delta of filesystem size, broken down by file type and/or directory
total and delta of code section sizes (.text, .data, .rodata, .bss, .sinit, etc)
When we have unit tests or functional tests (e.g. smoke tests) running, those results show up in the build log.
We've not thrown out anything yet -- given, our target builds usually end up at ~16 or 32 MiB per configuration, and they're fairly compressible.
We do keep uncompressed copies of the binaries around for 1 week for ease of access; after that we keep only the lightly compressed version. About once a month we have a script that extracts each .zip that the build process produces and 7-zips a whole month of build outputs together (which takes advantage of only having small differences per build).
An average day might have a dozen or two builds per project... The buildserver wakes up about every 5 minutes to check for relevant differences and builds. A full .7z on a large very active project for one month might be 7-10GiB, but it's certainly affordable.
For the most part, we've been able to diagnose everything this way. Occasionally there's a hiccup on the buildsystem and a file isn't actually a the revision it's supposed to be when a build happens, but there's usually enough evidence of this in the logs. Sometimes we have to dig out a tool that understands the debugging database format and feed it a few addresses to diagnose a crash (we have automatic stackdumps built into the product). But usually all the information needed is there.
We haven't had to crack the .7z archives yet, to mention. But we have the info there, and I have some interesting ideas on how to mine bits of useful data from it.
Save what can't be reproduced easily. I work on FPGAs where only the FPGA team have the tools and some cores (libraries) of the design are licensed to compile on only one machine. So we save the output bitstreams. But try to check them over one another rather than with a date/time/version stamp.
Save as in check in to source code control or just on disk? Save nothing to source code control. All derived files should be visible in the file system and available to developers. Don't checkin binaries, code generated from XML files, message digests etc. A separate packaging step will make these end products available. As you have the change number you can always reproduce the build if necessary assuming of course everything you need to do a build is completely in the tree and is available to all builds by syncing.
I would save your built binaries for exactly as long as they have a chance to go into production or be used by some other team (like a QA group). Once something has left production, what you do with it can vary a lot. For a lot of teams, they'll keep just their most recent prior build around (for rollback) and otherwise discard their builds.
Others have regulatory requirements to keep anything that went into production around for as long as seven years (banks). If you are a product company, I'd keep around any binary a customer might have installed in case a tech support guy wants to install the same version.