I would like to know, if e.g. 0.1.0 is already stable concerning a composer install.
I am familar with the SemVer Tags and I know, that the API can change with every realease which is not the first major (1.0.0) but still: the tag is a fixed state of the project.
So, will composer consider such a tag as stable or not?
From a semantic versioning perspective, it is not stable. However, Composer will treat (almost) all tags as having stability "stable".
Good to know: the ^ operator behaves very similarly to the ~ operator but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.
For more information, see https://getcomposer.org/doc/articles/versions.md
Related
I have a utility service x which is in maven repo and is used by some of my other services. We normally update the minor version of the service x when we make small changes and we are currently on version 1.0.15.
No I am making another change and I was thinking whether I should update version to 1.0.16 or I should update the version like 1.1.0.
If anyone can provide an explanation on how this should be done in general, that would I am sure help other developers as well as me. Please let me know if you need further information.
Different projects follow different standards on this, so follow what the repository has done to date.
A well-regarded standard for this is called Semantic Versioning (https://semver.org/). If you are starting a new project or there isn't a standard already in place, I would recommend using this.
Semantic Versions are in the format: MAJOR.MINOR.PATCH.
If you have fixed a bug: increase the patch version
If you have introduced new functionality in a non-breaking way: increase the minor version (and reset patch to 0)
If you have introduced breaking changes: increase the major version (and reset the patch and minor version to 0).
If you are unsure whether your change is a breaking change or not - consider your package (or API) from its consumers' perspectives. If their code has to change as a result of your change then it's a breaking change.
I'm using Yarn and when I installed my packages, I wanted to update them. I am really new to this so I having trouble understand what each one meaning.
An explanation would be helpful as I am not getting it from Googling.
(I am using this to install and working with SPFx).
yarn outdated v1.17.3 outdated
info Color legend :
"<red>" : Major Update backward-incompatible updates
"<yellow>" : Minor Update backward-compatible features
"<green>" : Patch Update backward-compatible bug fixes
Edit: - Finally think I understand..
red = Major Update. The updates are NOT backward-compatible.
yellow = Minor Update. The updates have backward-compatible features.
green = Patch Update. The updates are just patches to fix bugs, and are backward-compatible.
Please correct if wrong.
You are quite correct. NPM packages use Semver (Semantic Versioning) to indicate a package version. The version number isn't merely just an incremented number, it tells you a bit about what happened with an upgrade.
So you will most of the time have a version numbers that look like 1.2.3 or (MAJOR.MINOR.PATCH), where:
MAJOR - Big changes that changes the way the package is used, so you might need to update how you use/call the corresponding package. The update is thus not backward compatible.
MINOR - New functionality was added to the corresponding package, your code doesn't have to change. The change is backward compatible.
PATCH - No features were added, patches normally include bug fixes or small optimisations to a package.
Sometimes there is more meta data in the version number, for example 1.0.0-rc.1
indicates that this is a Release Candidate. Other examples include 1.0.0-alpha or 1.0.0-beta.
You can read more on Semantic Versioning at https://semver.org/
I am using a quite recent version of ruby (2.5.1) but some old gems. I am having some issues. I was wondering, is it correct that some gems work only with certain versions of ruby?
If a gem worked with ruby 2.3.0, is it true that it will definitely work with 2.5.1 (i.e. because 2.5.1 > 2.3.0)? Or is that not always the case?
I guess what I'm asking is are newer ruby versions always backwards compatible with older gems?
If a gem worked with ruby 2.3.0, is it true that it will definitely
work with 2.5.1
This is not correct. Programming languages are evolving while growing. This means language maintainers are doing lots of improvements or refactorings that they are new features or removing old components from the language. When the language community announces for new features or removing old feature such as Fixnum in ruby, the developers should follow the instructions and refactor their codebase accordingly. In other words, developers should have a good test coverage to detect any fail and fix it instantly.
In your scenario, as well as I understand you do not have a test coverage. The only but the simple thing should do is just upgrade your gems' versions to latest.
Gem is simply a plug-in library written in Ruby.
Of course, Ruby is developing, new features are appearing, old ones are disappearing.
It's best practice to specify Ruby version in .gemspec file. For example, like this one.
But if not, then you have to manually check the performance. So you can read gem source code or try to use your gem and check it.
For automation, of course, it is best to use tests.
Starting at Ruby 2.1.0 the version policy has been that a change in the MINOR version may introduce API breaking changes.
Should any gem happen to use an API that changes, an incompatibility will arise.
The MINOR version number has changed twice between 2.3.* and 2.5.* so even if a gem happens to have been written in accordance with the documented API, there's no guarantee that it will continue to work unless the gem's maintainer takes the effort to test the gem (and upgrade it if necessary). Automated test suites help a lot.
A standard way to document version compatiblity that is actually tested against is by providing required_ruby_version in .gemspec files.
Interestingly, if a particular gem is really badly written, I imagine it might break even between compatible versions of Ruby. That's not something I've encountered in the Ruby ecosystem but I've made a similar mistake writing Java code (and Java is famous for its backward compatibility) where my own code accidentally used a class that wasn't part of the API. There are many gems. Who knows what's out there? :)
In node projects, package.json lets contributors know what version of node they can use to either consume or contribute to a specific project. Python uses venv to control the version used in collaborative development environments, and many other languages have similar constructs as well.
Does go have a standardized process that allows you to do something similar?
No, but Go has the 1 promise of compatibility - they try very hard not to break any extant software built on 1.x, even at the expense of leaving an ugly API or unwanted behaviour (though this is rare). This means you don't really have to worry about specifying which version of Go you use. Go 2 is not even on the horizon, so for the foreseeable future, you don't have to worry about this. There are a few new features, but most go users upgrade (because of the stable upgrade path).
https://golang.org/doc/go1compat
Re which dependencies you have, at present the only solution is to put your dependencies into a vendor folder, but I think you were asking about the language specifically.
I have built my first ruby app there: https://rubygems.org/gems/youtube_dlhelper. As shown in Versions the correct versions are available: 0.1.0, 0.1.1 and 0.1.2.
But it looks like rubygems lists just the oldest 0.1.0.
Maybe anyone knows why?
The latest version of your gem is not showing up as the default because it does not conform to the Semantic Versioning specifications. Although it may seem obvious to us as humans that 0.1.2.alpha is greater than 0.1.0.alpha, a quick look at the spec shows that this is the incorrect way to specify a pre-release. Here's a relevant excerpt (emphasis added by me):
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
I'm not exactly sure how 0.1.2.alpha is being interpreted, but I think your best bet is to release a 0.1.3 version of your gem and yank the incorrectly versioned ones. You may even try releasing a 0.1.3-alpha, but I'd wait until someone more knowledgable can a give a more definitive answer.
In the meantime, I'd definitely encourage you to look at the Semantic Versioning specs.