请查看此页（“依赖项版本范围”部分）。你可能想做的是

<version>[1.2.3,)</version>

这些版本范围在Maven2中实现。

事实是，即使在3.x中，它仍然有效，令人惊讶的是项目的构建和部署。但是LATEST/REEASE关键字在m2e和eclipse中引起了问题，同时项目也依赖于通过LATEST/RERELEASE部署的依赖性，无法识别版本。

如果您试图将版本定义为属性，并在其他位置引用它，这也会导致问题。

因此，如果可以的话，结论是使用版本maven插件。

我在maven 3.5.4中的解决方案，在eclipse中使用nexus：

<dependency>
    <groupId>yilin.sheng</groupId>
    <artifactId>webspherecore</artifactId>
    <version>LATEST</version> 
</dependency>

然后在eclipse:atl+F5中，选择快照/发布的强制更新

这对我有用。

与其他人不同，我认为有很多原因可以解释为什么你总是想要最新版本。特别是如果您正在进行连续部署（我们有时一天会发布5个版本），并且不想进行多模块项目。

我所做的是让Hudson/Jenkins为每个构建执行以下操作：

mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true

也就是说，我使用版本插件和scm插件来更新依赖项，然后将其签入源代码管理。是的，我让我的CI进行SCM签入（对于maven发布插件，无论如何都必须这样做）。

您需要设置版本插件以仅更新您想要的内容：

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>1.2</version>
    <configuration>
        <includesList>com.snaphop</includesList>
        <generateBackupPoms>false</generateBackupPoms>
        <allowSnapshots>true</allowSnapshots>
    </configuration>
</plugin>

我使用发布插件来进行发布，该插件负责-SNAPSHOT，并验证是否存在-SNAPSHO的发布版本（这很重要）。

如果您执行我所做的操作，您将获得所有快照版本的最新版本和发布版本的最新版。您的构建也将是可复制的。

使现代化

我注意到一些评论询问了此工作流的一些细节。我会说，我们不再使用这种方法了，maven版本插件存在缺陷的主要原因是它本身就存在缺陷。

这是有缺陷的，因为要运行版本插件来调整版本，pom需要存在所有现有版本才能正确运行。也就是说，如果找不到pom中引用的版本，版本插件就无法更新到最新版本。这实际上相当令人讨厌，因为我们经常因为磁盘空间的原因清理旧版本。

实际上，您需要一个独立于maven的工具来调整版本（因此您不需要依赖pom文件才能正确运行）。我用低级语言Bash编写了这样一个工具。该脚本将像版本插件一样更新版本，并将pom检查回源代码管理。它的运行速度也比mvn版本插件快100倍。不幸的是，它不是以公共使用的方式编写的，但如果人们感兴趣，我可以这样做，并将其放入要旨或github中。

当一些评论问及我们的工作时，返回工作流：

我们有大约20个项目在他们自己的存储库中，他们有自己的jenkins工作当我们发布maven发布插件时，将使用该插件。该插件的文档中介绍了其工作流程。maven发布插件有点糟糕（我很友好），但它确实有效。有一天，我们计划用更优化的方法来替代这种方法。当其中一个项目发布后，jenkins会运行一个特殊的作业，我们称之为更新所有版本作业（jenkins如何知道它的发布是一个复杂的方式，部分原因是maven jenkins发布插件也很糟糕）。更新所有版本作业了解所有20个项目。它实际上是一个聚合器pom，以依赖关系顺序特定于模块部分中的所有项目。Jenkins运行我们神奇的groovy/bash-foo，它会将所有项目更新到最新版本，然后签入pom（同样是基于模块部分的依赖顺序）。对于每个项目，如果pom发生了更改（由于某些依赖项的版本更改），它将被检入，然后我们立即ping jenkins为该项目运行相应的作业（这是为了保持构建依赖项顺序，否则您将受到SCM轮询调度程序的支配）。

在这一点上，我认为无论如何，将发布和自动版本作为一个独立于常规构建的工具是一件好事。

现在您可能会认为maven有点糟糕，因为上面列出的问题，但对于没有声明性易于解析的可扩展语法（也称为XML）的构建工具来说，这实际上相当困难。

事实上，我们通过命名空间添加自定义XML属性来帮助提示bash/groovy脚本（例如，不要更新此版本）。

注：

6年前，Maven 3中的插件依赖性“为了可复制的构建”，已经删除了上述最新和发布元版本。（对于常规依赖关系，它们仍然工作得很好。）有关插件依赖关系，请参阅此Maven 3兼容解决方案。

如果您总是想使用最新版本，Maven有两个关键字可以作为版本范围的替代。您应该小心使用这些选项，因为您不再能够控制正在使用的插件/依赖项。

当您依赖插件或依赖项时，可以使用LATEST或RELEASE的a版本值。LATEST是指特定工件的最新发布或快照版本，即特定存储库中最近部署的工件。RELEASE是指存储库中的最后一个非快照版本。通常，设计依赖于工件的非特定版本的软件不是最佳实践。如果您正在开发软件，您可能希望使用RELEASE或最新版本，以便在发布第三方库的新版本时不必更新版本号。当您发布软件时，您应该始终确保您的项目依赖于特定版本，以减少您的构建或项目受到不受您控制的软件版本影响的可能性。如果需要，请谨慎使用“最新”和“释放”。

有关详细信息，请参阅Maven书中的POM语法部分。或者参见本文档中的依赖版本范围，其中：

方括号（[&]）表示“闭合”（包括）。括号（（&））表示“开放”（排他）。

下面是一个示例，说明了各种选项。在Maven存储库中，com.foo:myfoo具有以下元数据：

<?xml version="1.0" encoding="UTF-8"?><metadata>
  <groupId>com.foo</groupId>
  <artifactId>my-foo</artifactId>
  <version>2.0.0</version>
  <versioning>
    <release>1.1.1</release>
    <versions>
      <version>1.0</version>
      <version>1.0.1</version>
      <version>1.1</version>
      <version>1.1.1</version>
      <version>2.0.0</version>
    </versions>
    <lastUpdated>20090722140000</lastUpdated>
  </versioning>
</metadata>

如果需要对该工件的依赖性，您可以选择以下选项（当然可以指定其他版本范围，只需在此处显示相关版本）：

声明精确版本（始终解析为1.0.1）：

<version>[1.0.1]</version>

声明显式版本（将始终解析为1.0.1，除非发生冲突，否则Maven将选择匹配的版本）：

<version>1.0.1</version>

声明所有1.x的版本范围（当前将解析为1.1.1）：

<version>[1.0.0,2.0.0)</version>

声明开放式版本范围（将解析为2.0.0）：

<version>[1.0.0,)</version>

将版本声明为最新版本（将解析为2.0.0）（从maven 3.x中删除）

<version>LATEST</version>

将版本声明为RELEASE（将解析为1.1.1）（从maven 3.x中删除）：

<version>RELEASE</version>

注意，默认情况下，您自己的部署将更新Maven元数据中的“最新”条目，但要更新“发布”条目，您需要从Maven超级POM激活“发布概要文件”。您可以使用“-Prelease profile”或“-DperformRelease=true”执行此操作

值得强调的是，任何允许Maven选择依赖性版本（最新版本、释放版本和版本范围）的方法都会让您面临构建时问题，因为后续版本可能会有不同的行为（例如，依赖性插件先前将默认值从true切换为false，结果令人困惑）。

因此，在版本中定义准确的版本通常是一个好主意。正如Tim的回答所指出的，maven版本插件是更新依赖关系版本的便捷工具，特别是版本：使用最新版本和版本：使用最近版本目标。

您是否可能依赖于在开发过程中明显变化很大的开发版本？

不增加开发版本的版本，您可以只使用快照版本，在必要时覆盖快照版本，这意味着您不必在每次微小更改时更改版本标记。类似于1.0-SNAPSHOT。。。

但也许你正在尝试实现其他目标；）