以下策略规定在 30 天后删除对象的当前版本,并在 30 天后删除先前版本。
现在假设我于 4 月 1 日在启用版本的存储桶中上传一个对象,然后于 4 月 10 日上传相同的对象。
如果我没有上传第二个版本,当前对象将在 4 月 30 日被删除。
所以我的问题是,如果我在 4 月 10 日上传了第二个版本,会发生什么。
新版本和旧版本都会在5月10日删除吗?或者,旧版本会在4月30日删除,新版本会在5月10日删除吗?
{
"Rules": [{
"ID": "DeletionOfFileBasedOnQATag",
"Status": "Enabled",
"Expiration": {
"Days": 30
},
"NoncurrentVersionExpiration": {
"NoncurrentDays": 30
}
}
]
}
Run Code Online (Sandbox Code Playgroud) 当我尝试从命令行运行工具时出现错误。我创建了一个 setup.py 文件并将入口点放在一起。当我克隆存储库并安装在其他计算机上时,此命令行实用程序可以工作。我想知道这个问题是否与包位置中包含的开发标签有关。('this_tool==0.1.1.dev11')
通过python setup.py --version在 0.1.1.dev16 上使用它。但我不确定如何解决此问题,因为重新运行 setup.py 安装似乎无法解决问题。
Traceback (most recent call last):
File "/Users/USERNAME/miniconda2/envs/USERNAME/bin/this_tool", line 30, in <module>
sys.exit(load_entry_point('this_tool==0.1.1.dev11', 'console_scripts', 'this_tool')())
File "/Users/USERNAME/miniconda2/envs/USERNAME/bin/this_tool", line 22, in importlib_load_entry_point
return next(matches).load()
StopIteration
Run Code Online (Sandbox Code Playgroud)
如果需要的话我也可以提供我的 setup.py ,但由于它似乎可以在其他计算机上工作,我认为这不是问题
问题如下。我们有 2 个本机应用程序(ios 和 android)连接到 Firestore 后端。我们当前的数据模型存储分布在 5 个不同集合中的用户信息(个人资料数据、用户答案、用户法律文件等)。这意味着,很多时候,当我们需要查询有关用户的数据时,我们需要进行多个查询并手动将它们连接在一起以获得我们需要的数据。将所有信息存储在一个集合中对我们来说要简单得多。这是我们现在遇到的问题,而且随着我们业务的不断发展,我们会有更多的情况需要改变数据模型的结构。
\n目前,我们使用Firestore API在前端查询user\xe2\x80\x99s数据以进行实时更新。ATM 我们不\xe2\x80\x99t 使用自定义端点,因此我们\xe2\x80\x99t 没有任何类型的版本控制。
\n是否有任何最佳实践或策略来执行此类数据模型迁移而不强制用户升级到应用程序的最新版本?
\n我们可以想一些解决办法:
\n不断发展的数据模型以及多个 FE\xe2\x80\x99 消耗数据的问题非常常见。通常的最佳实践是拥有一个 FE 与之通信的版本化端点,以打破对数据模型的直接依赖。然而,Firebase 似乎并没有为此提供一套最佳实践。这对我们来说听起来有点奇怪,因为这是一个非常常见的问题,而且 Firebase 开箱即用地解决了许多其他常见的挑战。
\n我们缺少什么?
\n相关问题:\n https://www.reddit.com/r/Firebase/comments/dyhzlv/best_practices_of_versioning_with_a_firestore/
\n谢谢!
\nversioning data-modeling firebase firebase-realtime-database google-cloud-firestore
我想在源代码中手动定义软件的版本号。至少主要版本、次要版本和补丁版本组件(术语取自Semantic Versioning 2.0.0)。但是,对于构建元数据和.NET 的程序集修订版本组件,我希望它们能够被构建服务器自动覆盖。例如,在开发环境(开发人员桌面)中,构建元数据和程序集修订版本组件始终为空。0(例如 SemVer“1.2.3”,程序集“1.2.3.0”)。当开发人员签入代码更改时,构建服务器会使用格式yyMMdd(夜间构建)替换构建元数据和程序集修订版本组件。使用已经给出的示例,结果将类似于 SemVer“1.2.3+200721”和 Assembly“1.2.3.200721”。
我正在开发的软件是一个.NET Core 3.1 C#应用程序,使用 Visual Studio 2019 编写。因此,我将dotnetCLI 与单个解决方案文件结合使用,引用多个 C# 项目(一个主要项目和多个支持库)。对于最终的构建/发布(仅构建一个主要项目),我想使用如上所述的每晚自动发布的当前日期覆盖构建元数据和程序集修订版本组件。
构建服务器是GitHub Actions。这是我的工作流程脚本:
name: "Solution.sln (main)"
# Controls when the action will run. Triggers the workflow on push or
# pull request events but only for the master branch.
on:
push:
branches: [ "develop" ]
pull_request:
branches: [ "develop" ]
# A workflow run is made up of one or more jobs that …Run Code Online (Sandbox Code Playgroud) 我想将 OData 版本控制添加到 .NET 6 项目。项目中包含的软件包有:
显然 'Microsoft.AspNetCore.OData.Versioning' v5.0.0与 'Microsoft.AspNetCore.OData' v8.0.4不兼容。
两个包的组合会导致错误:
CS7069 对类型“ODataModelBuilder”的引用声称它是在“Microsoft.AspNetCore.OData”中定义的,但找不到
是否存在新包或者是否已将其合并到 Microsoft.AspNetCore.OData 包中?
Sam XU 提供了一个解决方案;创建扩展:https://devblogs.microsoft.com/odata/api-versioning-extension-with-asp-net-core-odata-8/这仍然是要走的路,还是在使用 OData 时有其他选择>= 8.0.4?
我正在看一个setup.py具有以下语法的:
from setuptools import setup
setup(
...
tests_require=["h5py>=2.9=mpi*",
"mpi4py"]
)
Run Code Online (Sandbox Code Playgroud)
我理解 ">= 的想法,其中h5py至少应该是 2.9 版本,但我一生都无法理解=mpi*之后的内容。是不是说版本应该以某种方式与 mpi 版本匹配,同时至少为 2.9?
我找不到任何解释指定 python 包版本的内容,也解释了单个=.
我发现它使用的唯一其他地方是一些晦涩的博客文章,似乎暗示它有点像使用别名导入包,这对我来说没有多大意义;还有mpi4py 文档,其中包含命令行片段conda install -c conda-forge h5py=*=mpi* netcdf4=*=mpi*,但并未真正解释它。
我想知道在推送你的应用程序的实时新版本时,你如何处理显示发布版本号?
您可以$Rev$在文件中使用以获取最新版本,但只能在更新文件后使用.
如果我每次更改存储库/目录中的任何文件时都想更新一个文件中的字符串,该怎么办?
有办法吗?
我需要澄清两种情况:
使用.NET 3.5编译的可执行文件需要使用使用.NET 1.1编译的库,并且库必须在1.1运行时上运行.
使用.NET 1.1编译的可执行文件需要使用使用.NET 3.5编译的库.
我找不到一个可靠的来源,说明无法加载两个版本的.NET运行时,而且微软的文档在这个问题上非常模糊.
这可能是一个天真的问题,但是,正如对象中所要求的那样,版本化软件将分支合并回主干而不会产生破坏代码的实际方式是什么?
这是一个简单的例子:我在"Hello World Power edition"程序的主干中创建了一个分支.我添加了对Klingon的支持.这是一个彻底改变,改变了printHelloWorld()函数的工作方式.
同时,由于bug#749导致"Hello World"被写为"Helo World",主干中的函数printHelloWorld()已被更改.
现在,我在这里看到的问题是:当我通过分支合并回主干时,我在文件sayHello.py中的函数printHelloWorld()中实验冲突
如何做一个VCS程序知道如何从我的分支中加入克林贡支持和保持bug修复在主干?什么是人为驱动或软件驱动的策略来避免这种情况?
提前致谢.