使用修补程序对分布式应用程序的程序集进行版本控制
我们正在开发一个具有多个物理层上的组件的应用程序，共享许多程序集以及每个层独有的一些程序集。
我想知道发布修补程序或仅应用程序的几个组件的典型版本控制策略是什么。
我们的问题跟踪软件包含整个产品的版本号。 如果当前版本是 1.4.5 并且需要修补程序，则修补程序的问题将针对 1.4.6 发布。 受 1.4.6 修复影响的所有程序集的版本均为 1.4.6。 如果我们只分发这些文件，我们最终会得到一些版本 1.4.5 的文件和一些版本 1.4.6 的文件。
解决方案可能是将整个应用程序重建并发布为 1.4.6，但这将需要重新部署多台计算机上的多个组件，并导致实际未更改的组件出现不必要的停机时间。
人们针对这个问题采取了哪些策略？ 是否只是接受某些文件具有不同版本号的问题？ 过去我发现这会导致客户（1 级）支持团队感到困惑。
We are developing an application with components on multiple physical tiers, sharing many assemblies as well as having some exclusive to each tier.
I am wanting to know what the typical versioning strategy is for release hot-fixes, or only a few components of the application.
Our issue tracking software contains a version number for the entire product. If the current version is 1.4.5 and a hotfix is required, the issues for the hotfix are to be released against 1.4.6. All assemblies affected by the fixes for 1.4.6 are versioned 1.4.6. If we distributed just those files we end up with some files on version 1.4.5 and some on 1.4.6.
A solution could be to rebuild and release the entire application as 1.4.6 but this would required multiple components on the multiple machines to be redeployed and result in unnecessary downtime of the components that didn't actually change.
What strategies have people put in place for this issue? Is it just a matter accepting that some files will have different version numbers? In the past I have found that this causes confusion with the customers (level 1) support team.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你提出了一个有趣的问题。
这实际上是您需要做出的一项策略决策，以决定您的部署和版本控制策略，并考虑各种因素的权衡（您已经注意到其中一些因素，例如客户的困惑）。
您可以做的事情之一就是将各个层的发布和版本控制分离，这将允许您在层内保持一致的版本控制，同时减少修补程序部署开销。 您还需要将通用程序集分解为单独的包和独立的版本。
这可能有点过分了，所以另一种选择是让你的版本控制更容易掌握。 例如，您可以保留版本号的一部分来指示修补程序。 例如，如果 1.4.5.0 是正式版本，则修补程序将为 1.4.5.1，这可以很容易地理解为是 1.4.5 正式版本的一部分。
您还可以使用其他程序集版本（例如
AssemblyInformationalVersion）来存储用户的版本信息。 （查看我的博客文章，了解有关< code>AssemblyInformationalVersion 和 .NET 中的程序集版本控制。）You pose an interesting question.
It's really a policy decision that you need to make to decide what your deployment and versioning strategy will be, and consider the trade-offs of various factors (some of which you have already noted, such as customer confusion).
One of the things you could do is to decouple the release and versioning of your individual tiers, which would allow you to have consistent versioning within a tier with reduced hotfix deployment overhead. You would also need to factor out the common assemblies into a separate package and version that independently too.
This might be overkill, so an alternative would be to make your versioning easier to grasp. For instance, you could reserve a part of your version number to indicate hotfixes. For example, if 1.4.5.0 is the official release, the hotfix would be 1.4.5.1 and this can be easily understood to be part of the 1.4.5 official release.
You can also use other assembly versions, such as the
AssemblyInformationalVersionto store version information for your users. (Check out my blog post for more details onAssemblyInformationalVersionand assembly versioning in .NET.)