I've found chronicle-queue version on maven central is quite old: 4.5.27, while 4.6.23 is most recent released on github. Does it mean 4.5.27 is a kind of "prod-ready", while all 4.5.27+ are experimental? Or you use other repositories for distribution?
The 4.5.27 version is stable and available to all users.
The 4.6.x version is being developed and available to supported clients. We expect to make a public release of this version this month.
Related
Several latest ML Kit stable packages like:
com.google.mlkit.image-labeling-common-17.1.0
com.google.mlkit.object-detection-common-17.1.0
and google play service artifacts like:
com.google.android.gms.play-services-mlkit-text-recognition-16.3.0
com.google.android.gms.play-services-mlkit-barcode-scanning-16.2.0
com.google.android.gms.play-services-mlkit-face-detection-16.2.0
depend on prerelease/preview package com.google.android.odml.image-1.0.0-beta1
Note: I did not investigate transitive dependencies.
When can release of com.google.android.odml.image-1.0.0 be expected?
We are actively working on it, but don't have an ETA yet.
I'm getting "One or more of the requested capabilities are not supported." error when trying to mount a volume from Amazon EFS on AWS FARGATE.
Edit your service and update "Platform version" to 1.4.0
You can do this in terraform by adding an optional variable platform_version to the aws_ecs_service resource
Here is the official AWS communication about the platform version 1.4.0
Here is an important quote:
The primer blog post goes into more detail about the philosophy behind why we introduced Fargate platform versions and, for example, the practical reasons why we are not tagging platform version 1.4.0 as LATEST just yet.
The primer blog post is here. Keep the focus on this "critical" point:
Starting with the introduction of this platform version (1.4.0), we will hold on moving the LATEST tag. We want to provide a runway for users that use LATEST as an additional precaution. This means that if you are deploying today using the tag LATEST to identify a Fargate platform version, the system will keep referencing platform version 1.3.0 for now (albeit, technically, the latest platform version available today is 1.4.0).
These users could either start experimenting with 1.4.0 by explicitly deploying to it or wait until we move the tag LATEST to point to platform version 1.4.0. [Updated on 6/17/2020] We plan to make this change in the May 2020 time frame We plan to make this change at some point in Q3/2020, thus giving customers [Updated on 6/17/2020] about a month a few months to test 1.4.0 before it gets tagged as LATEST. Expect a formal announcement for this change.
This is intended to give users a window of time to test 1.4.0 without being forced to use it if they use the tag LATEST. We do not anticipate disruption but we decided to be conservative.
That's why you should use, at the time of writing, version 1.4.0, instead of LATEST in order to use AWS EFS.
I need to build my project with Worklight version 6.1.0.02.20141216-0421, but I didn't find it. Please who has this version ?
If you absolutely must have this specific build, you can find it here if you use Worklight Consumer Edition, or here if you use Worklight Enterprise Edition, if you are an IBM customer with a valid support entitlement.
However, if there isn't a very specific reason that you absolutely must have this specific build, I strongly agree with Idan's answer that you should use the most recent iFix build available on IBM Fix Central. As of right now, the latest build contains fixes for 93 separate APARs that are not contained in the build you are asking about (from more than 2 years ago).
That is an extremely old build and unless this build was an official iFix release - it will no longer exist. So, if you are an IBM customer you can look for this build number in the IBM Fix Central website.
Note however that you should always use the latest available iFix release... and not a build from more than two years ago, especially for production. If you will request official support, you will be told to use the latest build.
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.
Is there a good reason to continue deploying newer snapshots, if there's already a released artifact of the same version?
Concretely: There's already xyz-1.0
There's projects continuing to have xyz-1.0-SNAPSHOT dependencies.
It appears wrong to me, but maybe there is some reason behind this?
If 1.0 has already been released, the snapshot should not be built any longer and you should probably remove the snapshot from your repository. If new development starts, it should be on 1.1-SNAPSHOT (or 1.0.1-SNAPSHOT, however you decide to do your versioning).
The only time that a project should be deploying snapshots after a release version has been deployed is if it were an alpha, beta, milestone or release candidate.
As you have suggested the projects in question are doing things wrong. After the xyz-1.0 release the SNAPSHOT versions should be updated to the next development version, 1.0.1, 1.1, or 2.0.