标签: versioning

是否存在使用句点而不是软件版本的任何其他分隔符的历史原因？

我们的产品之一是以前的3.5版本,现在它是3.08 - 我确信这是管理层说,一旦我们达到3.10,那么设置一个领先的零将使我们的客户更容易混淆.但作为软件开发人员,版本3.08对我来说很奇怪.

如果我们没有使用句点,版本3:9和3:10或3-9到3-10之间的差异会更明显,因为它不会被读作十进制数.此外,对于通常不熟悉软件版本控制的人来说,十进制数似乎意味着版本3.5已经到了下一个主要版本的一半,而实际上我们无法对下一个主要版本的次要版本数做出任何假设.

我知道现在我们通常使用句号作为约定,因为这是其他人正在做的事情 - 但是有没有理由在第一时间使用句号？

我有一个包含带时间戳的快照工件的存储库.

我想创建一个包含依赖项的程序集.这很好用.但工件名称包含时间戳.所以我想知道如何仅从程序集的文件名中删除时间戳.

我已经使用了这个dependencySet:

<outputFileNameMapping>${artifact.artifactId}-${artifact.version}.${artifact.extension}</outputFileNameMapping>

但版本接缝已包含时间戳.那么有没有机会获得1.1.1-SNAPSHOT而不是1.1.1-20100323.071348-182？

我正在使用maven-assembly-plugin的2.2-beta-4版本.

现在我们的程序集的版本号如2.0.831.0.据我了解,这是主要版本,次要版本,日期和内部版本号.如果我在同一天进行更改并再次构建,则为2.0.831.1,2.0.831.2等.

我的TeamCity构建数字格式只是2. {0}其中{0}是一个自动递增的数字,只是永远持续(2.195,2.196等).

如何使TeamCity看起来与装配版本完全一样？我们希望能够将更改日志与程序集版本相关联,因此任何人都可以说程序集版本2.0.831.2在这些文件中进行了这些更改.

额外信息:如果重要,我们的构建步骤使用"Visual Studio(sln)"选项而不是"MSBuild".如果重要,我们使用Subversion进行源代码控制.我们的TeamCity版本是6.5.1(build 17834).

如果我决定使用javascript或css文件的last_modified_time,并使用它的unix时间戳作为修改文件时胸围缓存的名称中的键.以下两种做法有什么区别？filename是:my_script.js,时间戳是:1321951817

1/File包含在: <script type="text/javascript" src="http://example.com/js/my_script.js?v=1321951817"></script> 因此,每次v更改时,查询字符串参数都会创建一个新的缓存.

2 /文件包含为: <script type="text/javascript" src="http://example.com/js/my_script.1321951817.js"></script> 文件名随每次修改而变化,重写规则删除时间戳并将请求的URL指向my_script.js

3/更新:基于以下答案的更多方法:文件被重命名并包括在: <script type="text/javascript" src="http://example.com/js/my_script.1321951817.js"></script> 文件名被更改并且使用NO REWRITE RULE.

问题:这两种技术本质上是否相同,或者使用查询字符串参数而不是直接文件名有任何优点/缺点.

是否有关于如何/在何处指定应用程序版本号的约定？

例如,对于ruby gems lib/mygem/version.rb,通常用于此目的的文件.

我的猜测是创建这样的config/version.rb文件:

module MySite
  VERSION = "0.0.4"

  # or in MySite::Application class
  # 
  # class Application
  #   VERSION = "0.0.4"
  # end
end

我希望以一种格式提供这些版本

像这样.. {Major}.{Minor}.{Build}.{patch}

如何在团队城市的程序集信息修补程序中设置它？

这样它每次构建时都会自动增加版本...

我想要一些指导和帮助...？!？

模块很酷,特别是当它们带有版本控制时.您可以定义最小模块版本以防止要使用的方法泄漏.但是每个光线都有一个黑暗的一面,这意味着Perl的TIMTOWTDI.

在作为Perl开发人员近七年后,我看到并以多种方式编写了版本声明.有些很容易被指出为坏,有些则不然.由于没有人能完全了解某种语言,所以我想问问你们,Perl中以下软件版本的优缺点是什么.

如果您发现一个泄漏,请不要犹豫,评论更多的版本定义方式;)

请尊重:

• 奇怪的需要/使用可能导致故障检测模块版本的模块(编译与运行时)
• PAUSE/CPAN解析(和其他常见服务)
• 最终用户的可读性
• 开发人员的可维护性

在Perl中声明包版本方法的优缺点是什么？

方法1

package PackageName;
BEGIN {
  use version 0.77; our $VERSION = version->new('v0.0_1');
}

方法2

package PackageName;
BEGIN {
  our $VERSION = 0.000_01;
}

方法3

package PackageName;
BEGIN {
  our $VERSION = 0.0.1;
}

方法4

package PackageName;
use version 0.77; our $VERSION = version->new('v0.0_1');

方法5

package PackageName;
our $VERSION = 0.000_01;

方法6

package PackageName;
our $VERSION = 0.0.1;

我目前正致力于将办公室的文件备份系统迁移到Amazon S3.基本的备份工作就像一个魅力,但我希望它更健壮.具体来说,我希望为存储桶中的文件添加版本控制(使用亚马逊"版本控制"),但没有提及(我可以找到)限制每个文件存储的旧版本数量的方法(即:"文件" x"在任何给定时间最多有5个以前的版本).

是否可以对每个文件存储的版本数量设置限制？或者,如果我走这条路线,我是否会随着时间的推移无限制地传播文件版本？

我一直在挖掘AWS论坛(以及我看的其他任何地方)并且还没有找到任何东西.任何信息,将不胜感激.谢谢!

在支持基于微服务的体系结构中进行版本控制的最佳实践是什么,在运行时支持同一服务的多个版本化部署以及消费者如何能够使用不同的版本？1)如果我们使用基于路由的版本控制作为这里提到的方法之一, 那么我想我们会有以下缺点

1. 内部服务必须通过反向代理才能使用.
2. 消费者必须始终了解所需的版本.

向消费者公开版本信息是最佳做法吗？

无论如何,我认为,以下内容始终适用:

1. 对于MAJOR版本更改,必须更改消费者.
2. 对于MINOR版本更改(向后兼容),只需要更改需要添加功能的消费者.
3. 对于PATCH版本更改,它是可选的,并且可能是任何消费者无缝使用它.

什么样的微服务版本控制策略可以帮助我们实现上述目标？

注意 - 如果需要分成多个问题,请随时告诉我.

我在Swift中开发应用程序为生。我喜欢这种语言，并且会尽可能地遵循它。但是，无论是事实还是事实，无论是我蒙蔽了我的视线，还是苹果公司对此保持沉默，都是如此。

今天，我发现Swift 3.3和3.4存在。我当时假设3.2是3的最新版本，可用于迁移到4、4.2和5。这种误解主要是由于Swift.org，官方Git存储库和Xcode发行说明没有牛逼何况他们在所有。

因此，我认为它们也是过渡性的，但是我不知道它们出现在什么IDE或编译器中，或者附带什么警告。下表总结了我的知识：

下表已过时，仅供参考，因此该问题很有意义。我在下面的答案中发布了此表的更新版本。

紫色空间中出现了什么？专门用于3.3和3.4行，但是如果您知道其他行，那也将有所帮助！

权威消息来源也很棒。

对主要问题的可能答案如下：

1. Swift 3.3仅在Xcode 9.3 beta中，从未公开。Swift 3.4仅在Xcode 9.3-9.4中
2. Swift 3.3仅在Xcode 9.3中受支持；Xcode 9.3.1和9.4支持Swift 3.4
3. Xcode 9.3和9.3.1支持Swift 3.3。Xcode 9.4仅支持Swift 3.4
4. Xcode版本9.3至9.4支持Swift 3.3。Swift 3.4仅在Xcode 10 beta中受支持。

我认为没有其他可能性。不过，请让我知道我是否不在基地。