我们的情况如下,但我对任何情况下的这个问题都很好奇.
我们有一个由4个项目组成的框架:
我们还有需要版本的模块,并且依赖于bean和util的版本.
最后,我们有一个客户项目,包括特定版本的核心项目和一个或多个模块.
是否有标准方法来版本化这些项目？
对我来说似乎很简单的事情变得非常复杂,因为我们尝试向QA提供版本,然后通过维护版本(release = tag和可能的分支)来管理我们的持续开发.
我更喜欢以下内容:
1.2.0 - 主要版本和次要版本+发布.
1.2.1 - 下一个版本
1.2.0_01 - 1.2.0版本中的错误修复(分支)
等等
有任何想法吗？
我想知道是否存在使用SVN对数据库进行版本控制的情况,当少数开发人员尝试同时提交更改时,这将确保没有冲突.
我和我的团队一直在使用更改脚本来增加架构版本号(类似于此解决方案:http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-change-scripts.aspx).
这是一个非常好的解决方案,但其主要缺陷是当多个开发人员尝试使用相同的模式编号提交更改脚本时可能发生冲突 - 这不仅是一个简单的SVN冲突,而且还要求具有该冲突的用户手动更改数据库表模式版本,还原其数据库更改,更改脚本文件的编号以获得所有数据库更新.是否有可能避免这种障碍？我不仅仅指技术解决方案,但也许有更好的方法来组织这项任务？有任何想法吗？
我刚刚编写了一个新版本的WCF Web服务,我想确保我没有对服务和数据合同进行任何重大更改.
回想一下我作为VB6 Com Api开发人员的日子,我记得在编译时指定组件的先前发行版本是多么容易,并让编译器检查是否正在维护二进制兼容性.
我设想类似的(希望是)"合同兼容性"检查.它将使用元数据执行与VB6 dev env所做的类似的检查.这可以作为执行实用程序的单独构建步骤来完成.
我准备接受那里没有这样的实用工具.如果是这种情况,是否有人对如何实现这一目标的算法有任何想法？
第3步似乎很复杂,但肯定是自动化的......
versioning wcf web-services metadata backwards-compatibility
我有一套Debian打包脚本,我希望每次构建时都会增加包的版本号.(即debian_revision如在指定的Debian策略手册)也就是说,第一个构建应该是PACKAGE-1.0-0,然后PACKAGE-1.0-0,等(这里1.0是upstream_version).是否有一种简单的方法来指定这个"额外"版本号而无需在更改日志中创建新条目？
我希望每当特定目标(即deb构建)时,由项目的Makefile自动完成此操作
我目前正在为Project Dash开发Maven工具.其中一个悬而未决的问题是如何处理错误.
Maven Central说:没有任何出版物发生变化.这是因为Maven从未试图弄清楚版本是否发生了变化(与SNAPSHOTs不同).
但我可能不得不创建一个新的"发布版",例如Eclipse 3.6.2的一部分.我应该使用哪个版本号？3.6.2.1,3.6.2-1,3.6.2_1,3.6.2pl1？为什么？
我需要一个普通用户可以编辑模型的系统,但是在管理员批准之前,编辑实际上不会发生.我发现了一个名为paper_trail的宝石,它确实有模型版本,但并不特别支持我想要做的事情.我想知道其他人是如何处理这个问题的.我应该补充一点,我希望能够让用户同时进行编辑.它们不是很复杂,例如一个是别名.
更复杂的部分可能是多个用户编辑相同模型并尝试进行某种合并的情况.
我想通过为不同版本提供不同的Accept标头值来对我的REST-Webservice进行版本控制(请参阅http://barelyenough.org/blog/2008/05/versioning-rest-web-services/).
问题是,Spring MVC 3似乎无法实现.
我的控制器看起来像这样:
@Controller
@RequestMapping("test")
public class RestController {
@RequestMapping(method = RequestMethod.GET, produces = "application/vnd.example.item-v1+json")
@ResponseBody
public ItemV1 getItem() {
return new ItemV1();
}
@RequestMapping(method = RequestMethod.GET, produces = "application/vnd.example.item-v2+json")
@ResponseBody
public ItemV2 getItem2() {
return new ItemV2();
}
}
当我尝试访问其中一种方法时,我得到一个异常:
java.lang.IllegalStateException: Ambiguous handler methods mapped for HTTP path '/test'
我错过了什么,或者Spring MVC是不可能的？我知道JAX-RS有可能......
当我听到关于发布版本1 API的讨论时,它始终伴随着这个基本的想法:
我们还不能发布我们的API,因为我们必须在第一时间做到正确.
这是Vic Gundotra最近的一个例子,但是在API发布前一天,还有很多其他的包括Stackoverflow本身.
我不明白的是,为什么第一个版本必须如此"正确"？使用API,您可以实现版本控制和良好的文档,如果您做得好,哪个并不难,为什么对版本1 API如此珍贵？
从版本到版本,因为它是版本化的,所以API可以在没有任何重大更改的情况下发生显着变化,因为仍然支持旧版本.我想知道为什么发布API的重大问题？
考虑使用特定版本化jar来实现方法的常见情况,但不公开公共或受保护API中该jar的任何类型(仅在私有方法的方法签名中).
现在我想要的是通过名称自动编译时链接此代码 - 修改原始包名称并将其替换为SBT中生成的代码(同样:我想在SBT中添加插件或在build.sbt中添加设置这样做每一个sbt compile).
这样做的目的是避免使用具有相同包/类名的类的多个可能不兼容的版本的类路径错误.注意:在我上面描述的情况中,内联或这个名称修改应该始终有效,并允许一个人走向版本地狱(以更大的罐子为代价).
我们有一个典型的N层.NET应用程序,它位于我们的数据库和Web API服务层之间.此应用程序包括业务层,数据存储库/访问以及相关的DTO和Business Objects.
我们有适当的解决方案来版本化我们的存储过程和Web API端点.问题是这个中间层版本的解决方案,实际的类方法和架构对象.所有Google搜索都会在源代码管理解决方案中提供源代码版本的结果,或者如何使用程序集信息进行版本化,这些都不是我们所指的,因此结果有限.
例如,我们有两个端点:
... api/v1/tax/charges
... api/v2/tax/charges
v1必须命中一个版本的方法CalculateTaxPctgs,v2命中另一个版本的更新业务逻辑.随着我们在v2中更改了一个字段的名称,需要使用不同版本的POCO Tax和TaxItems.
易于开发但难以管理且非常严格/静态的解决方案是创建两个不同的方法,CalculateTaxPctgs_V1和CalculateTaxPctgs_V2.这似乎不是一个好主意.
很难找到最佳实践,甚至是解决这种困境的替代解决方案.这是一个企业应用程序,每天需要数百万个请求,因此性能非常重要,但代码管理和可靠性也是如此.