标签: versioning

我自己和我的团队在增加程序集版本号时非常可怕,我们经常发送1.0.0.0版本的程序集.显然,这会引起很多麻烦.

我们通过CI平台实现了更好的实践,我真的想将其设置为自动增加assemblyinfo.cs文件中的值,以便使用该程序集中的代码更改自动更新程序集的版本.

我之前已经设置(在我们找到Hudson之前)通过任一msbuild或者命令行(不记得)增加值的方法,但是使用Hudson,这将更新SVN存储库并触发另一个构建.由于Hudson每小时轮询SVN,这将导致缓慢的无限循环.

让Hudson增加版本号是一个坏主意吗？什么是另一种方法呢？

理想情况下,我的解决方案标准是:

• 在构建assemblyinfo.cs之前增加内部版本号
• 仅增加已更改的程序集中的内部版本号.这可能是不可能的,因为Hudson每次执行构建时都会清除项目文件夹
• 将更改的assemblyinfo.cs提交到代码存储库(当前为VisualSVN)
• 在下次扫描更改时,不会导致Hudson触发新构建

在我脑海中解决这个问题,我可以通过批处理文件/命令轻松地提出大部分解决方案,但是我的所有想法都会导致Hudson在下次扫描时触发新的构建.我不是在找人为我做任何事情,只是指出我正确的方向,也许是让Hudson忽略某些SVN提交的技巧等.

到目前为止我发现的所有内容都只是一篇文章,解释了如何自动增加版本号,没有考虑到可以旋转到无限循环的CI平台.

我一直在寻找如何使用Spring 3.2.x管理REST API版本,但我找不到任何易于维护的东西.我先解释一下我遇到的问题,然后解决一个问题...但我想知道我是否在这里重新发明了这个问题.

我想基于Accept标头管理版本,例如,如果请求具有Accept标头application/vnd.company.app-1.1+json,我希望spring MVC将此转发给处理此版本的方法.并且由于并非API中的所有方法都在同一版本中发生更改,因此我不希望转到每个控制器并更改任何版本之间未更改的处理程序.我也不想有逻辑来确定控制器本身使用哪个版本(使用服务定位器),因为Spring已经发现了要调用的方法.

因此,采用版本1.0到1.8的API,其中版本1.0中引入了处理程序并在v1.7中进行了修改,我希望以下列方式处理它.想象一下,代码在控制器内部,并且有一些代码能够从头部中提取版本.(以下在Spring中无效)

@RequestMapping(...)
@VersionRange(1.0,1.6)
@ResponseBody
public Object method1() {
   // so something
   return object;
}

@RequestMapping(...) //same Request mapping annotation
@VersionRange(1.7)
@ResponseBody
public Object method2() {
   // so something
   return object;
}

这在春天是不可能的,因为2个方法具有相同的RequestMapping注释并且Spring无法加载.这个想法是VersionRange注释可以定义一个开放或封闭的版本范围.第一种方法从版本1.0到1.6有效,而第二种方法从版本1.7开始(包括最新版本1.8).我知道如果有人决定通过99.99版本,这种方法会中断,但这是我可以忍受的.

现在,由于上面的内容是不可能的,如果没有对Spring的工作方式进行认真的修改,我就会考虑修改处理程序与请求匹配的方式,特别是编写我自己的方式ProducesRequestCondition,并在那里有版本范围.例如

码:

@RequestMapping(..., produces = "application/vnd.company.app-[1.0-1.6]+json)
@ResponseBody
public Object method1() {
   // so something
   return object;
}

@RequestMapping(..., produces = "application/vnd.company.app-[1.7-]+json)
@ResponseBody
public Object method2() {
   // so something
   return object;
}

通过这种方式,我可以在注释的产生部分中定义关闭或打开的版本范围.我工作的这个解决方案现在,随着我仍然不得不更换一些核心Spring MVC类(的问题RequestMappingInfoHandlerMapping …

安装ASP.NET MVC 3安全更新后KB2990942,MVC版本似乎从3.0.0.0增加到3.0.0.1.这会导致Visual Studio不再找到引用.

<Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Resharper没有显示任何问题,但构建失败,有许多未解析的MVC类型和警告:

警告:无法解析此引用.无法找到程序集"System.Web.Mvc,Version = 3.0.0.0,Culture = neutral,PublicKeyToken = 31bf3856ad364e35,processorArchitecture = MSIL".检查以确保磁盘上存在程序集.如果您的代码需要此引用,则可能会出现编译错误.

这种做法很有道理.我的机器上不再存在此版本.

我无法保证dev机器,构建服务器和生产服务器上的确切MVC版本.他们可能有3.0.0.0或3.0.0.1可能随时改变.Windows Update可能随时发布新的MVC版本.此外,每当发布MVC更新时,我都不希望增加所有*.csproj文件中的版本号.

更新会影响多个版本:

• KB 2993939:Microsoft ASP.NET MVC 2的安全更新
• KB 2993937:Microsoft ASP.NET MVC 3的安全更新
• KB 2993928:Microsoft ASP.NET MVC 4.0的安全更新
• KB 2992080:Microsoft ASP.NET MVC 5.0的安全更新

安全公告:MS14-059:ASP.NET MVC中的漏洞可能允许安全功能绕过(2990942)

处理这种情况的最佳方法是什么？如何在未来的MVC更新中展开构建和生产并保持安全？

我希望我的应用程序的version属性为每个构建增加,但我不确定如何在Visual Studio(2005/2008)中启用此功能.我试图将AssemblyVersion指定为1.0.*但它并没有让我得到我想要的.

我也使用了一个设置文件,并且在早期的尝试中,当程序集版本发生更改时,我的设置被重置为默认值,因为应用程序在另一个目录中查找了设置文件.

我希望能够以1.1.38的形式显示版本号,因此当用户发现问题时,我可以记录他们正在使用的版本,并告诉他们如果他们有旧版本则升级.

还将理解版本控制如何工作的简短说明.构建和修订号何时增加？

版本REST URI的最佳方法是什么？目前我们在URI本身有一个版本#,即.

http://example.com/users/v4/1234/

对于此表示的第4版.

该版本是否属于queryString？即.

http://example.com/users/1234?version=4

或者版本控制最好的另一种方式？

作为构建过程的一部分,我需要为所有已编译的二进制文件设置版本信息.一些二进制文件已经有版本信息(在编译时添加),有些则没有.

我希望能够应用以下信息:

• 公司名
• 版权声明
• 产品名称
• 产品描述
• 文件版本
• 产品版本

所有这些属性都由构建脚本指定,并且必须在编译后应用.这些是使用C++ Builder 2007编译的标准二进制文件(而不是程序集).

我怎样才能做到这一点？

我们正在使用PHPCI和作曲家.运行PHPCI的服务器在PHP 5.3上.

对于一个项目,我们使用composer添加了Facebook PHP SDK.它需要PHP 5.4.Composer由PHPCI触发并执行.但是因为CI服务器刚刚得到PHP 5.3编写器失败并显示错误消息:

facebook/php-sdk-v4 4.0.9 requires php >=5.4.0 -> no matching package found.

当然,这让我在PHPCI中的构建失败了.

是否有可能跳过此要求？也许通过为composer.json添加一个选项？或者是composer.phar调用的参数？

我负责几个Excel文件和SQL模式文件.我该如何对这些文件执行更好的文档版本控制？

我需要知道这些文件中修改过的部分(不同部分)并保留所有版本以供参考.目前我在文件名上附加时间戳,但我发现它似乎效率低下.

有没有办法或好的做法来做更好的文档版本控制？

顺便说一句,编辑通过电子邮件发送给我文件.

Stack Overflow底部有一个subversion版本号:

svn修订版:679

我想在我的.NET Web Site/ApplicationWindows窗体,WPD项目/解决方案中使用这种自动版本控制.

我该如何实现？

我一直在阅读有关ReST API的版本控制策略,而且它们似乎没有解决您如何管理底层代码库的问题.

比方说,我们正在做了一堆破更改API的-例如,改变我们的客户资源,使其返回单独forename和surname领域,而不是一个单一的name领域.(对于此示例,我将使用URL版本控制解决方案,因为它很容易理解所涉及的概念,但问题同样适用于内容协商或自定义HTTP标头)

我们现在有一个端点http://api.mycompany.com/v1/customers/{id},另一个不兼容的端点在http://api.mycompany.com/v2/customers/{id}.我们仍在发布v1 API的错误修正和安全更新,但新功能开发现在都专注于v2.我们如何编写,测试和部署对API服务器的更改？我可以看到至少两个解决方案:

• 为v1代码库使用源代码控制分支/标记.v1和v2是独立开发和部署的,必要时使用版本控制合并将相同的错误修复应用于两个版本 - 类似于在开发主要新版本的同时管理本机应用程序的代码库,同时仍然支持以前的版本.

• 使代码库本身了解API版本,因此您最终会得到一个包含v1客户表示和v2客户表示的单一代码库.将版本控制视为解决方案体系结构的一部分而不是部署问题 - 可能使用命名空间和路由的某种组合来确保请求由正确的版本处理.

分支模型的明显优势在于删除旧的API版本是微不足道的 - 只是停止部署适当的分支/标记 - 但如果您运行多个版本,最终可能会遇到一个非常复杂的分支结构和部署管道."统一代码库"模型避免了这个问题,但是(我认为？)会使得在不再需要时从代码库中删除已弃用的资源和端点变得更加困难.我知道这可能是主观的,因为不太可能有一个简单的正确答案,但我很想知道在多个版本中维护复杂API的组织如何解决这个问题.