we want to use universal packages to store certain artifacts that our azure pipelines yaml build is producing. From the doc of universal packages I can see that semver is supported.
I am now asking what the exact string pattern for version of universal packages look like and if pre-release and build-metadata label (that is defined in semver) are supported too for universal packages.
Concretely would following versions be supported: 1.0.0-alpha+gitsha1 or 1.0.0+gitsha1 or 2.1.2-beta
Thank you
This is described clearly in our official doc here-- Publish a Universal Package
Update these values as desired, and use the feed name that you noted
earlier. Package names must be lowercase and can use only letters,
numbers, and dashes (-).emphasized text
Package versions must be lowercase Semantic Versioning (SemVer)
2.0.0 without build metadata (+ suffix).
So only 2.1.2-beta is supported in your given sample.
Related
I'm have a Latex template that still uses scrpage2. Since this library has been marked as outdated Miktex and Texlive both report File 'scrpage2.sty' not found. The recommendation is, to simply replace it with scrlayer-scrpage but if I do that, other things in the template, which is quite elaborate, break. My Idea was, to download the library from https://www.ctan.org/pkg/scrpage2, compile it and simply change the imports in the template to the locally compiled scrpage2.sty. Unfortunately the package only contains scrlettr.ins which in turn, when i run latex scrlettr.ins builds scrlettr.cls but not scrpage2.sty.
How do I get scrpage2.sty so I can use it locally?
Preface:
Using an old package version with a newer latex distribution can lead to all kinds of problems. Modifications to the kernel/class/other packages might be incompatible. My recommendation would be:
Solve the problems with scrlayer-scrpage and your template instead
If these problems can't be solved, use an older version of texlive which still has the package. You can find links to historic releases here: https://www.tug.org/historic/
To answer the actual question:
run tex scrpage2-obsolete.dtx to extract the .sty file
In flutter I'm little bit concussion to add package.
Rather than add package with version, is it best way to add package without version in pubspec.yaml file?
Might be, By default it will acquire latest version. But what happen when after adding new version will be available?
You can omit the version or use any, but it's a good idea to add a version range.
Avoid updates breaking your app/package
Specifying a version constraint helps to avoid unexpected breaking your app by running flutter packages get when new dependency versions become available that contain breaking changes (are not compatible with your old code).
You can then intentionally extend the version range for a dependency when you align your code to the new version of the dependency.
Dart and packages are supposed to follow Semantic Versioning which means when an update contains a breaking change, the major version number needs to be incremented.
For versions below 1.0.0 incrementing the minor version number indicates a breaking change.
The ^ is a shortcut to define a version range that indicates the defined version and all later versions that don't contain breaking changes.
So usually you would use
some_dependency: ">=2.0.0 <3.0.0"
or short
some_dependency: ^2.0.0
If some update fixes a bug in 2.1.0 that your application or package depends on you can use
some_dependency: ">=2.1.0 <3.0.0"
or short
some_dependency: ^2.1.0
Performance
Specifying a narrow version constraint also can make flutter packages get/upgrade faster especially when your application contains a lot of dependencies because this reduces the search space for packages get/upgrade that it needs to traverse to find a compatible set of dependencies.
Missing functionality
Please upvote https://github.com/flutter/flutter/issues/12627 to get proper information from flutter packages get/upgrade when newer dependency versions are available than your constraints allow (like pub get/upgrade does for non-Flutter Dart projects)
See also
https://www.dartlang.org/tools/pub/versioning
What does plus one (+1) mean in dart's dependency versioning
I know most projects have minimum versions defined in bower.json for a lot of libraries.
Something I don't understand is that would this be risky that if something updates and have break-changes or bugs, it will affect your application without you knowing it? What is the design thinking behind this?
Thanks!
We have just faced that exact issue on a project I am on, and the solution was to change our bower.json file to target fixed versions.
Specifically, we were targeting angularjs ^1.4.8. In AngularJS v1.6,
$location now uses '!' as the default hash-prefix for hash-bang URLs,
instead of the empty string
For better or for worse (mostly for worse) we had some hard-coded urls in a different application that pointed to this project that broke once bower automatically installed AngularJS 1.6 as part of our automated build process.
The solution was to simply lock down our versions rather than relying on the latest bug fix (i.e prefixing version numbers with ~) or minor build (i.e. prefixing version numbers with ^).
I think the reason that package managers like bower and npm default to dynamic versions is that they rely on semantic versioning, and in theory you should only encounter breaking changes when the major version number changes. Semver uses a major, minor, bugfix pattern. When the bugfix value is incremented it indicates that one or more backwards-compatible bugs have been resolved. When the minor version is incremented it indicates that new backwards-compatible functionality has been added. When the major version is incremented it indicates that new, breaking changes have been introduced.
The problem with this is that firstly, it relies on the package developer to respect the semver rules when they make changes to their packages, and secondly, even when semver is respected it can still lead to problems (as in the example I provided above).
In the document Support Statement for Visual Basic 6.0 on Windows... it states:
Localization Support Binaries
The following binaries are necessary for supporting Visual Basic 6.0
applications running on localized versions of the Windows operating
system. They are supported but are not shipped in Windows. These files
are required to be shipped with your application setup.
That seems pretty clear in itself.
For instance, mfc42jpn.dll is required for Japan, mfc42ita.dll for Italy, etc.
However, I cannot find any source of these files from Microsoft. Where can they be sourced?
Note - there are some random DLL download websites which turn up the correct filenames, but I'd far prefer an authoritative source.
You should apply SP6. According to this, it covers all English versions of these products, as well as all localized versions.
On the VB6 installation CD those files can be found in the \OS\SYSTEM folder.
For the OP's given example of MFC42.dll it includes:
MFC42.DLL
MFC42CHS.DLL
MFC42CHT.DLL
MFC42DEU.DLL
MFC42ENU.DLL
MFC42ESP.DLL
MFC42FRA.DLL
MFC42ITA.DLL
MFC42JPN.DLL
MFC42KOR.DLL
In the Delphi Project Properties dialog, there are settings for the "Product Version" and the "File Version". Can anyone explain the philosophical differences between the two?
The Product Version will be the version number of your whole application.
The File Version will be the version number of this component.
The two are usually in sync, but don't have to be. It would depend upon how modular your application was.
So for example you might have an application that's at version 2.3.4.0 (say), but one file reader component that's at version 5.6.7.0 as it was inherited from a different application and another at version 1.2.0.0 as it's a more recent addition.
Additionally, some components might not change between releases so theoretically they should remain at their original file version.
However, as this might well cause confusion (not least with the developer) about which file goes with which version of the product these numbers are often kept in sync.
Not all the files are to be changed when the product version changes.
E.g. you've written a dll implementing the core functionality that remains unchanged during following product version changes.
Product version is the version of the product the executable is a part of, like Firedox 3.5.2 - all files in the product should have the same version (for a given version, obviously). The file version is normally the version of the specific file, like the firefox executable, for example, without respect to the product. This doesn't seem to get used much.
In contrast to the file version the product version is not necessarily numerical. E.g. we use the pre-build scripts to set it to the current date. This way, we can easily check when an executable was built.