I want to know how to choose the versions of the dependencies used by azure-iot-sdk-c.
for example, I plan to use:
azure-iot-sdk-c from github.com/Azure/azure-iot-sdk-c.git, release_2018_02_09_after_bump_version(3deb0ca3a8e2d220a50175bef71d16d1650a3a79),
then how do I know the right submodule/library versions for it? for example, the sub-modules in https://github.com/Azure/azure-uamqp-c/releases, github.com/Azure/azure-umqtt-c.git ...?
Thanks in advance.
Software and library is managed using the version. And libraries should be designed backwards-compatible when the MAJOR version is same.
A common way to find the suitable version for GitHub project's sub-modules is looking the release date of that project. For example of Azure-iot-sdk-c_release_2018_02_09, the version sub-module of azure-uamqp-c is 1.x.x published before 09/02/2018, so we can use any version of 1.x.x azure-uamqp-c. And of cause, the recommend version should be the latest version of that major version(1.2.3) at present.
More detail about concept of version and sub-modules, you can refer the links below:
Working with submodules
Semantic Versioning 2.0.0
If anyone else lands here after searching the error message of 3deb0ca3a8e2d220a50175bef71d16d1650a3a79;
I found this (https://github.com/Azure/azure-iot-sdk-c/blob/main/doc/master_to_main_rename.md) which refers to azure iot branchn renaming from master -> main on Dec 1st -21, which may explain the trouble finding the reference.
By updating my *.bb file which refers to the github with:
git#linktoyourgit.com ;main
This will reference the specific branch main to find the correct revision.
Related
I try to develop a thirdparty unixODBC driver, it is a secondary development based on the original file libodbc.so.2.0.0.
so I want to rename 'libodbc.so.2.0.0' to 'libodbc.so.2.0.0_renamed'. And soft link my dynamic library file to libodbc.so.2.0.0.
But I found an issue bothering me, when I rename native file and run 'sudo ldconfig', the file named 'libodbc.so.2' automatically linked to the renamed file 'libodbc.so.2.0.0_renamed', as below:
I could not understand that:
why it occurs;
how to appropriately replace the library.
I don't have enough ackownledge about linux, so that I failed to get any keyword to search and deal with it.
Could you help me, thank you very much!
Shared objects under GNU/Linux follow a specific version naming scheme, which is known by the loader (and OS component, actually part of libc framework) to determine if a newer library is retro-compatible with some older version to which a binary was originally linked against. By adding the renamed suffix, you are violating the convention and the dynamic linking system is getting confused. You should renamed as suggested by #Bodo above.
In addition, perhaps rather than using rename, you might consider using the very versioning scheme. From GNU Build System (aka Autotools) manual, the version cheme is like it follows:
Versioning: CURRENT:REVISION:AGE
CURRENT The latest interface implemented.
REVISION The implementation number of CURRENT (read: number of bugs fixed...)
AGE The number of interfaces implemented, minus one.
The library supports all interfaces between CURRENT − AGE and CURRENT.
If you have
not changed the interface (bug fixes) CURRENT : REVISION+1 : AGE
augmented the interface (new functions) CURRENT+1 : 0 : AGE+1
broken old interface (e.g. removed functions) CURRENT+1 : 0 : 0
Therefore a possible history of your lib might be:
1:0:0 start
1:1:0 bug fix
1:2:0 bug fix
2:0:1 new function
2:1:1 bug fix
2:2:1 bug fix
3:0:0 broke api
3:1:0 bug fix
4:1:1 bug fix
5:0:0 broke api
You might, for instance, call the older and newer versions of libodbc.so.x.y.z, according to your needs. Just an idea.
Am I the only one who thinks that the pub package manager is a good base but lack some basic stuff (compare to Nugget on VS)?
Installing a new package is very easy : just add a line of code in the pubspec.yaml file.
But how do you manage updates? If you do not specify a version you've got almost automatic update, and if you do, you just don't have any update at all. Is there any way you can have notification when a package update is available, and chose one by one if you update it or not, based on the changelog?
Thanks!
Dart packages use semantic versioning.
TL;DR about semver:
major = breaking changes
minor = new features
patch = bug fixes.
Combined with version constraints you can have custom behavior.
For example, the following will accept only bug fixes for the 1.0.0 version of a package named some_package:
dependencies:
some_package: ^1.0.0
Similarly, this constraint accepts all newer releases besides breaking changes:
dependencies:
some_package: '>=1.2.3 <2.0.0'
See https://dart.dev/tools/pub/dependencies#version-constraints for more information.
That plugin is exactly what I was looking for!
https://plugins.jetbrains.com/plugin/12400-flutter-pub-version-checker
Combined with the sementic versionning explained by #Remi, it's perfect 👌
I am just curious, what is carbon, boron, argon which is used while describing versions of nodejs?
Actually Node.js provide code name for Long Term Support (LTS) versions.
It started from Argon (version 4.2.0 to 4.9.1). And then it went like Boron (6.9.0 to 6.16.0), Carbon(8.9.0 to 8.15.0) and Dubnium (10.13.0 to 10.15.0). Basically they name their LTS versions under Chemical elements.
Argon(Ar), Boron(B), Carbon(C) and Dubnium(Db).
They are the code names for the Nodejs versions (based on chemical names from the periodic table, names are taken alphabetically a, b, c ...), please check below link for more details,
https://nodejs.org/en/about/releases/
Now the second part,
Always try to use the stable and latest version (LTS) of Nodejs in production, currently, it is 12.18.3. But for experimenting you can go with the current version and play with new features.
With version 8+ you get async-await support of javascript in Nodejs
Don't bother with the previous version if you are starting new.
I don't know if I get your question right, but according to https://nodejs.org/en/blog/release/v8.9.0/, https://nodejs.org/en/blog/release/v6.9.0/, and https://nodejs.org/en/blog/release/v4.2.0/, these are the names of the releases.
I am trying to develop a simple project in Pharo, and I would like to add its dependencies in Metacello. My project depends on Glamour, Roassal and XMLSupport.
A way to cleanly install my project is to install the dependencies by hand first. Following the book Deep into Pharo one can do
Gofer new
smalltalkhubUser: 'Moose' project: 'Glamour';
package: 'ConfigurationOfGlamour';
load.
(Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault.
Gofer new smalltalkhubUser: 'ObjectProfile'
project: 'Roassal';
package: 'ConfigurationOfRoassal';
load.
(Smalltalk at: #ConfigurationOfRoassal) load.
Gofer new
squeaksource: 'XMLSupport';
package: 'ConfigurationOfXMLSupport';
load.
(Smalltalk at: #ConfigurationOfXMLSupport) perform: #loadDefault.
and then my project will work fine.
I have tried to create a ConfigurationOfMyProject using the Versionner, and I have added Glamour, Roassal and XMLSupport as dependencies, using the version that are currently installed in my image (2.6-snapshot, 1.430 and 1.2.1 respectively).
The problem is that I am not able to load my project using Metacello in a fresh image. The project loads fine, but whenever I try to load my classes I get method missing errors in Glamour. Moreover, it is apparent that something is different, because even the world menu has different entries.
I have tried other combinations of versions, including using the stable Glamour (2.1) but I have obtained more errors, including not even being able to open the project in the Versioner (it complains about a missing Roassal name).
What is the correct way to add these dependencies cleanly?
First of all I want to highlight that if configuration is in class ConfigurationOf<proj-name> you can load it as using #configuration message:
Gofer new
smalltalkhubUser: 'Moose' project: 'Glamour';
configuration;
load.
(Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault.
A I don't see your project, I can just suggest you to write configuration by hand. There is an easy tutorial called Dead simple intro to Metacello.
According to your description it should be something like:
baseline01: spec
<version: '0.1'>
spec for: #common do: [
spec blessing: #release.
spec repository: 'your repo url'.
spec
package: 'YourPackage' with: [
spec requires: #('Glamour' 'Roassal' 'XMLSupport') ].
"also maybe you have a couple of packages that depend on different projects"
spec project: 'Glamour' with: [
spec
className: 'ConfigurationOf Glamour';
repository: 'http://smalltalkhub.com/mc/Moose/Glamour/main';
version: #'2.6-snapshot' ].
spec project: 'Roassal' with: [
spec
className: 'ConfigurationOfRoassal';
repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal/main';
version: #'1.430' ].
"and same for XMLSupport" ].
Also you can try to load #development versions, as I have an impression that projects like Roassal and Glamour have very outdated stable versions. Also please note that Roassal2 is actively developed and will replace original Roassal in Moose platform, maybe you want to consider using it.
I would seriously discourage writing configs by hand - that is the assembly code of Metacello ;) Unless you are working on cross-Smalltalk-platform projects with platform-specific code (e.g. code for Pharo 1.4 vs Squeak 4.5) - an area which hasn't been explored yet, Versionner is the tool for you. I have written dozens of configs with it and have yet to run into a roadblock.
When you say you added them as dependencies, did you just add them as projects in the "Dependent projects" pane?
If so, you also have to specify which of your project's packages depend on them. To do this, you select the relevant package of your project on the "Packages" pane.
Now, click on the edit button with the pencil icon that just became enabled. In the dialog that appears, click the green + button and add the external projects of interest.
It looks like you are trying this in an old version of Pharo?
Roassal has been superseded by Roassal2, and the support for XML is on smalltalkhub, split into ConfigurationOfXMLWriter and ConfigurationOfXMLParser, both in PharoExtras.
If you load the right groups from Glamour you don't need to describe the dependencies on Roassal, as Glamour already depends on Roassal(2). That explains your cyclic dependency.
You have also run into the problem we've recently talk about on the pharo mailing lists
that #stable is not a usable symbolic version name. In the Seaside/Magritte/Grease projects we've changed to using #'release3.1' style symbolic version names. That ensures that there is less of a ripple effect when progressing stable.
Snapshot versions should never be a dependency, they just describe what is loaded at the moment, and are basically not upgradable.
[edit]
Metacello by default tries to be smart about not installing older versions over newer. This works pretty well as long as things are not moved to different packages. So it's a bit of bad luck there that you ended up with a non-working combination.
Metacello support complex workflows, and different smalltalk projects (need to) use different workflows. It often takes some time to reach consensus on the best way to do things.
Roassal does not depend on Glamour, but you can create the cycle in your own configuration :)
Packages were moved from squeaksource to ss3 and smalltalkhub because the server had had stability problems. More recently, those problems seem to have been fixed. The xml support was split as it was noted that a lot of applications actually don't need both writing and reading of xml.
Once you have a working configuration, it might be a good idea to build and test it on the continuous integration server of pharo: http://ci.inria.fr/pharo-contribution
If not your actually application, at least the open source parts as used by you. That way the Pharo, Glamour & Roassal teams can know if a change they make breaks something.
Using Installshield 2011, we're creating a major upgrade and having problems upgrading software with this Product Version format - 2009.727.1365. We keep getting the standard 'Installed software is newer than product to be installed' message. With IS 2011, the major version has to be less than 255, from what I can gather, and I think the old format we're using is breaking the check for upgrading.
I've created a test IS project upgrading from 1.00.0000 to 2.00.0000 with no issues, so I'm thinking the issue has to be related to the format of the product version already installed.
Is there a way to use InstallScript or something to compare our old format with the new one and then do an override?
Any help would be greatly appreciated. Thanks in advance!!
**I ended up using Christopher's reply in the link he provided below (Exceeding Version Limits). This seemed to handle the uninstallation of the existing product very well. Thanks again Guys!
It sounds as if you'll need to remove or modify the ISPreventDowngrade major-upgrade item, which is what detects and prevents this kind of version downgrade (and which is usually what one wants).
(Posted follow-up to question here, too: http://community.flexerasoftware.com/showthread.php?t=195076.)
Your ProductVersion property is invalid. The SDK says:
The value of the ProductVersion property is the version of the product in string format. This property is REQUIRED.
The format of the string is as follows:
major.minor.build
The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.
I also recommend reading Exceeding Version Limits.
There are hacks to work around this if you understand how FindRelatedProducts and RemoveExistingProducts works.
Even though this is an older I'd like to add my two cents.
I am creating an Installshield 2012 Spring project and I had the same issue.
Our previous installers had a Product Version in the format 2005.xx.xxxx. Obviously this 2005 was an issue.
Instead of setting the ISACTIONPROP1 property to any value (as mentioned in http://community.flexerasoftware.com/showthread.php?195076-Old-Product-version-in-2009-727-1365-format).
I added a major upgrade item with the following values:
Product code of the old installers: xxx (enter yours here)
Minimum version: 2005.001.0001
Maximum version: 2005.255.65535
Version Range Inclusive (might be overkill)
With this, the system does allow the 2005.xxx.xxxx format here. It detected and removed the previous installation. For our newer installations we will use our "normal" versions:
5.008.0001
5.009.0001
...