In a pom.xml, when specifying a dependency version, what is the difference between LATEST and [0,) ?
In my opinion they should be equivalent, but for some dependencies, LATEST does not match any version, whereas [0,) does.
In my opinion they should be equivalent, but for some dependencies, LATEST does not match any version, whereas [0,) does.
In theory, LATEST is the latest released or snapshot version (see Rich Seller's excellent answer on the special RELEASE and LATEST versions) so I would indeed expect the same behavior as with the [0,) range. Out of curiosity, can you provide an example where LATEST doesn't match?
That being said, I don't recommend using the LATEST nor RELEASE special versions as they make your build more fragile and harm the build reproducibility (you don't really want your build to suddenly start to fail because of some uncontrolled update). Admittedly, they're considered as a bad idea and references have been removed from the documentation (except from an untranslated part of the German version of the Definitive Guide)
and they are no longer supported in Maven 3.x.
You are thus strongly invited to not use them at all (bad practice, deprecated, not supported in the next version).
And I somehow consider the same applies to version ranges (in general), I don't recommend them either as I wrote many times in previous answers or comments. See for example:
Managing maven dependancies - New Versions and Non-Repo libraries
Maven automatic SNAPSHOT update
Debugging Maven’s “The artifact has no valid ranges”
Follow-up after comment
Here's an example (among many):
<dependency>
<groupId>aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>[0,)</version>
</dependency>
-> matches version 1.5.3 Whereas:
<dependency>
<groupId>aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>LATEST</version>
</dependency>
-> cannot be resolved
I'm not 100% but I don't think this artifact is providing the right maven-metadata.xml for this feature to work. I think metadata should include <release> and <latest> elements like for maven plugins (see for example this maven-metadata.xml). But I wouldn't spend too much time on this for the aforementioned reasons, just forget this LATEST stuff.
When you depend on a plugin or a
dependency, you can use the a version
value of LATEST or RELEASE. LATEST
refers to the latest released or
snapshot version of a particular
artifact, the most recently deployed
artifact in a particular repository.
RELEASE refers to the last
non-snapshot release in the
repository. In general, it is not a
best practice to design software which
depends on a non-specific version of
an artifact. If you are developing
software, you might want to use
RELEASE or LATEST as a convenience so
that you don't have to update version
numbers when a new release of a
third-party library is released. When
you release software, you should
always make sure that your project
depends on specific versions to reduce
the chances of your build or your
project being affected by a software
release not under your control. Use
LATEST and RELEASE with caution, if at
all.
See, for further information regarding this topic.
Make sure that the artifact you're looking for is present in your local repository.
However, I have to warn you about the LATEST and RELEASE version markers, as the documentation extract says, it is consider a bad practice to work with those. In fact, I think the LATEST and the RELEASE version markers will no longer be supported in Maven 3.X.
My recommendation is that you drop it usage completely and stick to the specific version notation.
EDIT:
Here is a POST that addressed this exact same information, but more thoughtfully.
Thanks to #Pascal Thivent for the observation :) I always include reference to the other StackOverflow questions that deal with the same subject I'm discussing.
Related
How does different mikro-orm packages versions correspond to each other? Could I possibly use #mikro-orm/core 4.0.0 and #mikro-orm/nestjs 3.1.0 or other variations of different #mikro-orm packages and their versions? Should all #mikro-orm packages be installed with same version?
It's 3 questions but I feel they are pretty much the same since they try to clarify concept of version matching in mikro-orm for me.
All packages that come from the main repository are released together, you should always align their versions.
https://github.com/mikro-orm/mikro-orm/tree/master/packages
The rest is not dependent on exact version, but in general, use the most up to date one. There are currently 3 packages that live outside of the main repo, the nest adapter you mentioned and 2 highlighters.
Btw there is no such release as #mikro-orm/nestjs 3.1.0, first release was 4.0.0 and current is 4.2.0.
edit: apparently lerna is aligning only minor/feature releases, so it can happen that some packages are not on the very latest patch version, example of that are mongo and reflection packages, that are still on 4.1.0, while the rest is on 4.1.1. but again, use the latest everywhere and you will be fine. Your IDE should guide you in knowing the latest versions.
I'm maintaining some js library. Releases follow SemVer. Current stable version is 1.5.0. I'm working on 1.5.1 and have 1.5.1-beta.2 which is published at npm with "next" tag. Today I got bug report, discovered the issue and ready to fix it. The thing is that 1.5.1 is not going to be finished during nearest days, it turned out to be more complicated than I planned initially. But I want the fix to be published.
What is the right strategy in this situation? Obvious approach which I'd like to avoid is to postpone the bug fix until 1.5.1 is done and published and then release 1.5.2 containing the fix.
Another way is to publish the fix as 1.5.1 based on 1.5.0 and then continue previous work switching it from 1.5.1-beta.2 to 1.5.2 or even 1.6.0. I'm concerning about inconsistency with the result chain in this case:
1.5.0 → 1.5.1-beta → 1.5.1-beta.1 → 1.5.1-beta.2 → 1.5.1 (bug fix, based on 1.5.0) → 1.5.2 (based on 1.5.1-beta.2)
How such collisions are being addressed using SemVer?
Okay, so you have bug set A currently baking as 1.5.1-beta2 and you have a new bug set B that you want to get the fix out for immediately. The correct mechanism for this is to fork 1.5.0, fix bug set B, and release 1.5.2 (assuming you don't need a beta). Then merge your B fixes into your A working branch and release 1.5.3-beta1 and proceed to drive that to an official release.
It gets a little more complicated when you have two parallel beta sequences running, particularly when you're not sure which is going to make it to release first, but it is manageable. The key is to to just keep in mind, how SemVer precedence impacts the decisions your customers make (the algorithms they apply), whether to fast-track a particular version into their production systems, verses how their developers pull bits from you.
My production systems, have two inputs:
Development is the product of my engineers.
Automated maintenance is the product of a system that:
Pulls patch releases and applies them to a fork of my current production code.
Tests the applied changes against an extensive suite of functional and performance tests.
If the tests are green, flight tests the changes in my production environment, while monitoring for unusual changes in production failure rates.
As long as everything is going well and a human doesn't step-in to stop it, eventually rolls out the changes to the entire production system.
There are of course, variations for services and packaged products. The point is, you can use your release points to signal to your customers automation, or developers, that you have an important bug fix that has little risk of breaking anything. There is no requirement that 1.5.2 have any lineage back to 1.5.1-beta#. You are not required to ever release a 1.5.1. It is customary however to add a comment in your release notes that 1.5.2 is a hot fix for the bug in 1.5.0 and does not contain the fixes in 1.5.1-beta#.
While you may never encounter a need to do so, you don't have to include the bug fixes from 1.5.2 in your eventual 1.5.3 release, provided the later release, passes your quality controls. It is sometimes the case that a specific bug fix, winds up not being applicable in later releases.
How you maintain your product quality is entirely up to you. How you signal the level of risk/importance for a specific release, is defined by the SemVer standard.
I've created a new project by checking the "include kotlin" box in Android Studio 3 and out of the box I get an error while compiling
"Failed to resolve: org.jetbrains.kotlin:kotlin-stdlib-jre7..."
I have made sure all plugins are up to date and that the Android SDK is properly installed.
How can I solve for this error?
kotlin-stdlib-jre[7/8] was deprecated a while ago, and has since been removed. The deprecation note was kept until 1.2.71, which was the last version to release those artifacts. The official deprecation notice can be found here. Using any of the deprecated versions (before it was removed) should also produce a warning in (at least) Android Studio and IntelliJ.
Use kotlin-stdlib-jdk7 instead. It's the same dependency as kotlin-stdlib-jre7 (except newer), but it was re-named to kotlin-stdlib-jdk. kotlin-stdlib-jre is now no longer maintained as a separate dependency.
Both IntelliJ and Android Studio currently generate new projects using kotlin-stdlib-jre7; this likely is a bug. They have probably not updated the project generators. Therefore, you have to manually replace the dependencies with working ones until they fix this. This is dependent on the Kotlin plugin. Update it if you haven't. I haven't checked whether it's been patched or not - if it has, that only fixes the creation of new projects. For updating from older versions, the rest of the answer still applies
You naturally have to do this if you're on 1.2.71 or lower, and you're upgrading to 1.3.0 or higher.
These are the new valid dependencies as of Kotlin 1.3.0:
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
Where $kotlinVersion is either a variable containing the version, or a hard-coded version (i.e. 1.3.0)
Alternatively, you can use the "plain" stdlib (kotlin-stdlib) instead of the JDK-specific versions. But you have to change your dependency either way, so I recommend you go with kotlin-stdlib-jdk7, or if you plan on using Java 8, kotlin-stdlib-jdk8
The newest versions of the dependencies can also be found here. jdk7, jdk8, and the version-unspecific stdlib all follow the same versions (as per this edit - this could change in the future, but there'll likely be notices before that change happens), so whether you check jdk8, jdk7 or the regular one, all the versions should be universally available across the stdlib artifacts.
Note for other build systems
The same actual solution applies to other build systems as well, but the code is different. As there are a lot of build systems, I'm not going to include all of them, but the point is changing the artifact from kotlin-stdlib-jre[num] to kotlin-stdlib-jdk[num] (without brackets of course). Or, as mentioned earlier, kotlin-stdlib.
Independently of the build system, this bases itself on access to Maven Central and similar repositories. If your build system doesn't support this, and/or breaks with Maven-style conventions and repositories, you'll have to find what works for your build system.
TL;DR:
Use org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version or org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version (depending on which version you originally used) instead.
Remove this line from the build.gradle:
implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
Add this line in the build.gradle:
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
Update the version build.gradle in project level:
kotlin version='1.3.0'
In CMakeLists.txt scripts, it is customary to have a:
cmake_minimum_required(VERSION x.y)
for the appropriate x.y version number. But - how can you tell what that minimum version is? I don't work with older versions; and as my distribution gets updated, so does CMake, so I may have even introduced commands requiring newer versions over time and I just don't know it.
I could theoretically require the versions I've tested this CMakeLists.txt with - but they're pretty new, and I don't want to restrict users of my code to just that.
There is no automatic way to do this. Here are some approaches I've used:
If you have used CMake for a while, you may roughly remember what features are newer and older. Select some of the features you use which you think are newer, and read the documentation to discover what version supports them.
If you can install just one or two old versions, it may be enough. CMake 2.8.x is very popular, so installing that and testing to see if it works (perhaps fixing it so it does) would be a nice service to some users.
Don't worry about it. Set the minimum to 2.8.10 and then accept patches or bug reports if users have specific issues. It's not likely that setting this number too low will cause any serious harm--typically it will just result in a different error message than "The CMake version is too old."
tl;dr: Try building with different CMake versions.
Download the CMake binary from https://cmake.org/files/ according to the claimed minimal required version. You can unpack them in some directory and use this CMake to ensure it is still the minimal required version. You can have as many versions as you wish in parallel. Don't forget to delete the build directory.
A problem you did not mention, but is also important: Check your code with newer version. New policies can lead to dozens of warnings, many projects try avoiding warnings in releases. So it might be good to have the latest version with the same procedure.
New to Apache Ivy and I'm configuring the latest-strategies element in my settings file, and am opting to go with the lexiconographic strategy for a number of reasons. But something just dawned on me, and has me worried about Ivy in general. I'm sure I'm just not seeing the "forest" through the "trees", but I absolutely need to gain clarity on this before I can proceed.
My project will use several other homegrown JARs as dependencies. Other developers may be actively working on these other JARs, and may introduce a bug at some point. If my project uses Ivy to always pull down the latest version of these other dependencies, then Ivy may inadvertently pull down a new bug when it goes to build.
What's the common solution here, or what do best practices dictate?
Is there a way to cherry pick which versions of which JARs my project uses? That way I'm not concerned with latest-strategies at all, or lexiconographic order, etc. That would seem to alleviate the problem, but may violate best practices.
Any input is appreciated, as always!
In such situation we used to use tags on trunk. When developer creates tag he must change a version number of a published ivy module. In this case when you want to use stable version of module you could resolve it by certain version (1.2.3) or by latest version from some range (1.2.+). The latest-development strategy pull out the latest unstable trunk or branch version of a module.