标签: versioning

我的目标：

我们允许将我们的产品与由于许可而未作为我们产品的一部分安装的第三方组件（库）集成。目前我们只想加载与第三方组件相关的功能，前提是这些组件安装在客户端的机器上。

当前解决方案：

我正在使用Assembly.ReflectionOnlyLoad提供第三方程序集的全名来在应用程序加载相关功能之前验证第三方组件的安装。这适用于以下场景：

• 库的确切版本安装到 GAC
• 库的确切版本被复制到应用程序目录/探测路径

问题：

现在我需要修改解决方案以支持发布者策略（将程序集绑定重定向到新版本）。我刚刚测试了我的代码，它似乎ReflectionOnlyLoad忽略了部署到 GAC 的发布者策略，因此即使正确安装了第三方程序集（具有程序集重定向的新版本），我的机制也不会加载预期的功能。

如果我删除我的验证（= 每次都会加载功能），应用程序将正确加载新版本的第三方程序集，因此发布者策略可以正常工作，因为功能仍然依赖于旧版本进行编译。

使用版本控制和程序集重定向时，如何验证 GAC 和探测路径中程序集的存在？

我们有一个购物车,如下图所示,设置运行良好,除了一个致命的缺陷.如果您下订单该订单与产品相关联,那么如果我在您购买产品后更新产品,我就无法向您展示您希望产品在购买时的样子(包括价格).这意味着我们需要版本控制.

我目前的计划是,在创建新产品或变体或编辑现有产品或变体时,在数据库中创建产品或变体的副本.购买时,将订单链接到版本,而不是产品.

这似乎相当简单,除了我可以看到的,我们不需要版本的唯一事情是类别(因为没有人关心它的类别).所以我们需要版本:

• 制品
• 变种
• 每个版本的键 - >值对属性
• 图像

我目前的想法是,

注意: 创建产品时,也会创建默认变体,但无法删除.

• 创建产品时
  • 将产品插入产品表中.
  • 创建默认变体
  • 将产品复制到products_versions表中
    • 使用product_id列替换当前id列
    • 添加id列
  • 将变体复制到variants_versions表中
    • 用variant_id列替换当前id列
    • 添加id列
    • 将product_id列替换为product_version_id列

• 编辑产品时
  • 将产品更新到产品表中.
  • 将产品复制到products_versions表中
    • 使用product_id列替换当前id列
    • 添加id列
  • 将所有产品变体复制到variants_versions表中
    • 用variant_id列替换当前id列
    • 添加id列
    • 将product_id列替换为product_version_id列
  • 将所有variant_image_links复制到variant_Image_link_version表中
    • 将当前variant_id列替换为variant_version_id列

• 添加变体时
  • 将变体添加到变体表中.
  • 将产品复制到products_versions表中
    • 使用product_id列替换当前id列
    • 添加id列
  • 将所有产品变体复制到variants_versions表中
    • 用variant_id列替换当前id列
    • 添加id列
    • 将product_id列替换为product_version_id列

• 编辑变体时
  • 更新变体表中的变体.
  • 将产品复制到products_versions表中
    • 使用product_id列替换当前id列
    • 添加id列
  • 将所有产品变体复制到variants_versions表中
    • 用variant_id列替换当前id列
    • 添加id列
    • 将product_id列替换为product_version_id列
  • 将所有variant_image_links复制到variant_Image_link_version表中
    • 将当前variant_id列替换为variant_version_id列

所以最终结构看起来像全尺寸

现在这一切看起来都很棒,除非它看起来像是一堆重复数据,例如,如果我们更新产品,我们会复制变体,即使它们插入后也不会更新.此外,这似乎很多工作.

有没有更好的方法呢？

我想将当前的git分支放入pom xml的version字段中.我发现互联网上的一些帖子建议做类似的事情:

<version>${scm.version}</version>

但这似乎不适用于git.还有其他解决方案吗？

我正在Golang中创建一个用于移动应用程序的服务器.我需要能够为用户不更新应用程序的情况支持多个版本的API.版本控制的主要问题是以正确的格式返回移动应用程序版本的数据.

我已经看到有三种基本方法可以做到这一点.
A.一种方法是在"/"上设置一个路由处理程序,然后允许该函数解析用于版本控制的URL.
例:

func main() {
http.HandleFunc("/", routes.ParseFullURI)
}

B.使用诸如gorilla/mux之类的库来处理路由器中的模式,但我看到一些警告说这可能太慢了.
例:

  func main() {
            mux.HandleFunc("{version:}/", routes.ParseVersionForHome)
            mux.HandleFunc("{version:}/getData", routes.ParseVersionForGetDAta)
            mux.HandleFunc("{version:}/otherCall", routes.ParseVersionForOtherCall)
            }

C.让个别网址不改变,但基于标题,分成不同的版本.例:

func main() {
   http.HandleFunc("/", routes.ParseHeaderForVersionForHome)
   http.HandleFunc("/getData", routes.ParseHeaderForVersionForGetData)
   http.HandleFunc("/otherCall", routes.ParseHeaderForVersionForOtherCall)
}

我担心选项1代码太乱了.我担心选项2在性能方面会太慢,而且我担心选项3对于客户来说很难处理,或者由于版本没有明确标记而会让人感到困惑.

哪种方法最适合Golang,并且会为经常轮询的移动应用带来最佳性能？

我想向我的 MongoDB 中的文档添加版本控制。在 MongoDB 中是否有版本控制的最佳实践？在我的 MongoDB 中对文档进行版本控制的最简单方法是什么？

Google最近发布了适用于Android的新版Google API,让我感到非常奇怪,为什么他们会跳出3个主要版本.据我所知,他们没有在发行说明中解释它,所以我的问题就像标题一样.

为什么Google决定使用适用于Android的Google API从版本12.0.1升级到15.0.0？

我们刚刚开始研究可能最好被描述为公司范围的“开放”源代码框架的东西。我们的主要语言是 C#，我们使用 Jenkins 和 ProGet 来创建和共享 nuget 包。我们开始把所有东西（我的意思是所有东西。一个模块至少有三个存储库）放在它自己的 Git-repo 中。我们认为这是一个好主意，因为我们可以单独版本和发布所有内容，但如果您想对具有依赖项的多个存储库进行更改，结果会导致非常烦人的工作流程。

我开始环顾四周，似乎大多数项目都使用更加单一的方法，我认为这也可能会让我们在这里的生活更轻松。我不太确定的是，这种方法的版本控制是如何工作的。

CoreFx 存储库是我们正在努力实现的一个很好的例子。一个 repo 导致许多单独的包。当我在本地构建它时，所有包都有一个版本号，但是当我查看 nuget.org 上的可用包版本时，版本似乎是每个包的。例如 System.Diagnostics.DiagnosticsSource 版本为 4.5.1，但引用 System.Diagnostics.Debug 版本 4.3.0。

所以这正是我认为对我们来说是一个很好的解决方案。一个 repo，许多具有独立版本的结果包。

有谁知道这是如何通过 corefx 项目实现的，或者有任何其他建议，怎么做？

我目前正在开发社交应用程序。

我想在我的PHP后端上安装一个版本控制系统，但是我不知道从哪里开始：我在网上查找了很多文章，但是我真的不明白我所发现的内容。

假设我的应用程序是v1.0。然后，我创建了一个新版本v2.0，当然我也更新了PHP文件。此后，如果某人尚未从v1.0更新其应用程序，我希望他们能够访问myapp.com/v1.0/该应用程序，以免该应用程序崩溃。

你会推荐什么？

我的一个典型的PHP文件如下所示：

<?php

// Include files

include_once ('../../config.php');

include_once (ROOT_DIR . '/config/includes.php');

$_USERDATA = Validator::validateUser($_POST["userId"], $_POST["session"]);

// Valid session

$qry = $db->prepare('SELECT n.id, n.type, n.time, n.isRead, n.postId, n.commentId, n.text, n.inReplyToCommentId, u.id as byUserId, 
    ( SELECT COUNT(nu.id)
    FROM notificationUsers AS nu
    WHERE nu.notificationId = n.id ) as detail1,
    ( SELECT nu2.userId
    FROM notificationUsers AS nu2
    WHERE nu2.notificationId = n.id ORDER BY nu2.id DESC LIMIT 1 ) as latestUserId FROM notifications AS n LEFT JOIN userData AS …

关于后端实现的逻辑，我想确定什么可能被认为是 API 的 URI 版本控制的最佳实践。

假设我们有一个带有以下 API 的 Java 应用程序：

http://.../api/v1/user
Request:    
    {
      "first name": "John",
      "last name": "Doe"
    }

一段时间后，我们需要向用户 API 添加另外两个必填字段：

http://.../api/v2/user
Request:    
    {
      "first name": "John",
      "last name": "Doe",
      "age": 20,
      "address": "Some address"
    }

我们为每个版本使用单独的 DTO，一个有 2 个字段，另一个有 4 个字段。

我们只有一个应用程序实体，但我的问题是我们应该如何处理逻辑，作为最佳实践？可以仅在一项服务中处理此问题吗？

如果这两个新字段“年龄”和“地址”不是强制性的，这不会被视为重大变化，但既然是，我认为有几个选择：

• 对于所有用户 API 版本，在业务层仅使用一个管理器/服务（但代码的复杂性在于，只有一个管理器会随着时间的推移而增长很多，并且难以维护）
• 仅对所有用户 API 版本使用一个管理器，并使用一个类作为翻译器，这样我就可以使旧 API 版本与新 API 版本兼容
• 每个用户 API 版本的业务层中的新管理器/服务

如果我只对所有用户 API 版本使用一个管理器并在其中放置一些约束/验证，则 V2 将起作用，但 V1 将抛出异常，因为这些字段不存在。

我知道版本控制是一个很大的话题，但直到现在我才在网上找到具体的答案。我的直觉是，为所有用户 API 版本拥有一个管理器将导致一种与干净代码无关的方法，而且，我认为新版本添加的任何更改都必须尽可能松散耦合，因为将更容易弃用旧方法并及时删除它们。

在DevOps Pipeline 中构建我的 Android 应用程序时，我想从我的 gradle 脚本中访问预定义的Azure DevOps 变量，如下所示：

apply plugin: 'com.android.application'

// When running on the CI, this will return the build-number. Otherwise use 1
def buildNumber = System.getenv("Build.BuildNumber") as Integer ?: 1

android {
    compileSdkVersion 29
    buildToolsVersion "29.0.2"
    defaultConfig {
        applicationId "my.app.id"
        minSdkVersion 23
        targetSdkVersion 29
        versionCode buildNumber
        versionName "1.0." + buildNumber
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

    ...
}

在Bitrise 上，调用def buildNumber = System.getenv("BITRISE_BUILD_NUMBER") as Integer ?: 1工作得很好，但我不知道如何访问Azure DevOps Pipeline 中的Build.BuildNumber …