版本号的编制规范
This document covers how the APR projects are versioned. Since the APR projects are libraries, it is very important to define a stable API for users of the libraries. However, we also need to move the libraries forward, technologically. To balance these two needs, a strict policy of versioning is required, which users can rely upon to understand the limitations, restrictions, and the changes that can occur from one release of APR to the next.
?The Basics
?Source Compatibility
?Binary Compatibility
?Examples
?Strategy
?Version Checking
?Parallel Installation
?Other Notes
Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards.
It is important to note that a library that has not reached 1.0.0 is not subject to the guidelines described in this document. Before a 1.0 release (version 0.x.y), the API can and will be changing freely, without regard to the restrictions detailed below.
We define "source compatible" to mean that an application will continue to build without error, and that the semantics will remain unchanged.
Applications that write against a particular version will remain source-compatible against later versions, until the major number changes. However, if an application uses an API which has become available in a particular minor version, it (obviously) will no longer build or operate against previous minor versions.
We define "binary compatible" to mean that a compiled application can be linked (possibly dynamically) against the library and
continue to function properly.
Similar to source compatibility, an application that has been compiled against a particular version will continue to be linkable against later versions (unless the major number changes). It is possible that an application will not be able to successfully link against a previous minor version.
Here are some examples to demonstrate the compatibility:
Note: while some of the cells say "no", it is possible that the versions may be compatible, depending very precisely upon the particular APIs used by the application.
This section details how we will build the code to meet the above requirements and guidelines.
To retain perfect source and binary compatibility, a patch release can only change function implementations. Changes to the API, to the signatures of public functions, or to the interpretation of function parameters is not allowed. Effectively, these releases are pure bug fix releases.
Minor releases can introduce new functions, new symbolic and enumerated constants, and deprecate existing functions.
New functions
An application coded against an older minor release will
still have all of its functions available with their original signatures. Once an application begins to use a new function, however, they will be unable to work against older minor
versions.
It is tempting to say that introducing new functions might create incompatibility across minor releases. If an
application takes advantage of an API that was introduced in version 2.3 of a library, then it is not going to work against version 2.2. However, we have stated that an any
application built against version 2.2 will continue to work for all 2.x releases. Thus, an application that states
"requires 2.3 or later" is perfectly acceptable -- the user or administrator simply upgrades the installed library to
2.3. This is a safe operation and will not break any other
application that was using the 2.2 library.
In other words, yes an incompatibility arises by mandating that a specific version needs to be installed. But in
practice, this will not be a problem since upgrading to newer versions is always safe.
New constants
Similar to functions, all of the original (old) constants will be available to an application. An application can then choose to use new constants to pick up new semantics and
features.
Replacing functions
This gets a bit trickier. The original function must remain available at the link-level so that an application compiled against a minor version will continue to work with later
minor versions. Further, if an application is designed to work with an earlier minor version, then we don't want to suddenly change the requirements for that application. This means that the headers cannot silently map an old function into a newer function, as that would turn an application, say, based on 1.2 into an application requiring the 1.4 or later release.
This means that functions cannot truly be replaced. The new, alternate function can be made available in the header and applications can choose to use it (and become dependent upon the minor release where the function appears).
It is possible to design a set of headers where a macro will always refer to the "latest" function available. Of course, if an application chooses to use this macro, then the
resulting compiled-binary will be dependent upon whatever version it was compiled against. This strategy adds the new functionality for applications, yet retains the necessary source and binary compatibility for applications designed or built against previous minor releases.
Constants (enumerated values and preprocessor macros) are not allowed to change since an older application will still be using them. Similarly, function signatures at the
link-level may not change, so that support for older,
compiled applications is maintained.
Deprecating functions
Since a function must remain available for applications
coded against a previous minor release, it is only possible to "deprecate" a function. It cannot be removed from the
headers (so that source compatibility is retained) and it cannot be removed from the library (so that binary
compatibility is retained).
If you deprecate a function in APR, please mark it as such in the function documentation, using the doxygen
"\deprecated" tag. Deprecated functions can only be removed in major releases.
A deprecated function should remain available through the
original header. The function prototype should remain in the same header, or if moved to a "deprecated functions" header, then the alternate header should be included by the original header. This requirement is to ensure that source
compatibility is retained.
Finally, if you are deprecating a function so that you can change the name of the function, please use the method
described above under "Replacing functions", so that
projects which use APR can retain binary compatibility.
Note that all deprecated functions will be removed at the
next major version bump.
Major Versions
Any kind of change can be made during a major version release.
Particular types of changes that might occur:
?remove or change constants
?remove (deprecated) functions
?fold together macro-ized function replacements
In many cases, the user of a library will need to check the version that they are compiling against, or that is being used at runtime.
Because of the strict rules of source and binary compatibility, these checks can be simpler and more complicated depending on what is needed.
Libraries should make their version number available as
compile-time constants. For example:
#define FOO_MAJOR_VERSION 1
#define FOO_MINOR_VERSION 4
#define FOO_PATCH_VERSION 0
The above symbols are the minimum required for this specification.
An application that desires, at compile-time, to decide on whether and how to use a particular library feature needs to only check two values: the major and the minor version. Since, by definition, there are no API changes across patch versions, that symbol can be safely ignored. Note that any kind of a check for a minimum version will then pin that application to at least that version.
The application's installation mechanism should then ensure that that minimal version has been installed (for example, using RPM dependency checks).
If the feature changes across minor versions are source compatible, but are (say) simply different choices of values to pass into the library, then an application can support a wider variety of
installed libraries if it avoids compile-time checks.
A library meeting this specification should support a way for an application to determine the library's version at run-time. This will usually be emboded as a simple function which returns the MAJOR, MINOR, and PATCH triplet in some form.
Run-time checks are preferable in all cases. This type of check enables an application to run against a wider variety of minor releases of a library (the application is "less coupled" to a particular library release). Of course, if an application requires a function that was introduced in a later, minor release, then the application will require that, at least, that release is installed on the target system.
Run-time checks are particurly important if the application is trying to determine if the library has a particular bug that may need to be worked around, but has been fixed in a later release. If the bug is fixed in a patch release, then the only avenue for an application is to perform a runtime check. This is because an application cannot require a specific patch level of the library to be installed -- those libraries are perfectly forward and backwards compatible, and the administrator is free to choose any patch release, knowing that all applications will continue to function properly. If the bug was fixed in a minor release, then it is possible to use a compile-time check, but that would create a tighter coupling to the library.
Parallel installation refers to the ability to install multiple versions of a library simultaneously -- they exist in parallel. This document will not discuss the full rationale for why this is important, but will instead detail how this versioning specification maps onto those concepts. Please refer to Havoc Pennington's document for futher details and the rationale behind this form of parallel installation.
On Unix-ish platforms, the library name should include the MAJOR version number:
libFOO-MAJOR.so
This strategy allows an application to explicitly state which version of the library that it wants to link against. If the
application was built for version 2 of the API, then it can link against libFOO-2.so. If another application was built against version 3 of the API, then it links against libFOO-3.so. Since both libraries can reside on the system at the same time, both applications' needs can be satisfied.
Typically, shared libraries on Unix-ish platforms will set up symlinks from the .so library to specific versions of that library. For example:
libFOO-MAJOR.so -> libFOO-MAJOR.so.0
libFOO-MAJOR.so.0 -> libFOO-MAJOR.so.0.MINOR.PATCH
In this configuration, applications will be bound to the .so.0 library. The minor version does not come into play here because we want applications to dynamically load and link to the new library when a new minor version is installed. Thus, the MINOR and the PATCH values are relegated to the library name after the .so.0 portion.
The implication here is that build systems for libraries should arrange to generate .so libraries matching the above pattern.
The default installation directory for a library's include files should specify the MAJOR version number, and should normally be installed as a subdirectory in some standard location. For example:
/usr/include/FOO-MAJOR/
An application can place the FOO-MAJOR directory on its include path and include the files normally:
#include
#include
Depending upon the API that the application is designed to work against, it can simply include different versions of the include directory.
NOTE: There is no recommendation at this time for the best and proper handling of, say, FOO-config types of files. Or non-code types of files (e.g. things that typically get installed into areas like /usr/shared).
Further thought and exploration is needed here.
It is expected that other libraries, besides those in the APR project, will want to use the above definitions of versioning. This is quite fine, and those libraries can simply reference this document. Its canonical location is:
https://www.360docs.net/doc/ee18317698.html,/versioning.html
版本号由三个部分的整数组成：主版本号（MAJOR）、副版本号（MINOR）、补丁版本号（PATCH）。主要的含义是主版本号（MAJOR）是不兼容的，API大规模升级。副版本号（MINOR）在源文件和可执行版和老版本保持兼容，补丁版本号（PATCH）则意味着向前和向后的完全兼容
截关、截港、截单 截关：也叫截放行条时间，是指截止报关放行的时间，货物必须要在此时间之前做好报关放行的工作，递交海关放行条给船公司。在此时间之后再递交海关放行条，船公司将视该货物未能清关放行，不允许上船。一般是船开日前1-2天（散货是提前5-7天），而且一般是在截港时间后半个工作日。 截港：也叫截重时间，是指该时间之前，装好货的货柜可以入码头或入仓库，过了之后就不可以再进入码头，一般是船开日前1-2天。（散货是提前5-7天） 截关:必须在此日期之前报关 截港：必须在此之前让箱子回场站 截单：必须在此之前确认好提单，否则会产生改单费！ 顺序应该是截关、截港、截单。 截关就是指柜子上船前报关后，海关发放行条之时间，即是柜子要在截重（还重柜的截止时间）前送达码头，在截关前报好关，则在发放行条时段（一般为截关日的12点和5点）可获得放行条。 二截四开就是星期二截关，星期四开船。 简单的说截关时间就是在此时间前必须要通关,截单就是在此时间前提单必须要确认好,截港就是箱子在此时间前必须要送到指定的地点. 货代订到仓位后根据报关日期会给你一个有效的进仓时间，最晚在报关前一天必须进仓。过了有效进仓时间就截关，也就不能报关了。 货代订仓后会及时告诉进仓时间和地点，具体的要和货代联系。 截港期也叫截重时间，是指该时间之前，装好货的货柜可以入码头货入仓，过了之后就不可以再进入码头，一般是船开日前1-2天。（散货是提前5-7天） 截关日也叫截放行条时间，是指截止报关放行的时间，货物必须要在此时间之前做好报关放行的工作，递交海关放行条给船公司。在此时间之后再递交海关放行条，船公司将视该货物未能清关放行，不允许上船。一般是船开日前1-2天（散货是提前5-7天），而且一般是在截港时间后半个工作日。 截单日，是指船公司最后更改提单格式的时间，在此之前，提单格式和资料可以多次修改，在此之后，提单修改将会产生改单费用，这个时间没有标准，各个船公司不一样，有的是开船日，有的是开船后一周之内。 结关就是结重柜时间，一般在S/O表示为：CY CLOSING 海关输单截止时间：CUSTOMS DATA INPUT 结放行条是结报关文件，一般在S/O表为：CUSTOMS VOUCHER RELEASE 截补料时间：表示为：SI CUT TIME 时间顺序：结关在前，结放行条在后
1. 1.版本命名规范 软件版本号有四部分组成，第一部分为主版本号，第二部分为次版本号，第三部分为修订版 本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有五种，分别为base、alpha、beta 、RC 、 release 2. 2.软件版本阶段说明 Base：此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。 Alpha ：软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。测试人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将软件版本标注为alpha版。 Beta ：该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是软件的UI。 修改的的Bug 经测试人员测试确认后可发布到外网上，此时可将软件版本标注为 beta版。 RC ：该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。 Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。该版本有时也称标准版。 3. 3.版本号修改规则
（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。此版本号由项目决定是否修改。 （2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 （3）修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重 Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 （4）日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。 （5）希腊字母版本号：此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。 4.版本发布周期 （1）非紧急情况：首先由测试人员测试并提交Bug，其次开发人员会尽量在当天修复Bug并在第二天发布该版本的alpha版，然后由测试人员测试验证关闭Bug之后在第三天会发布该版本的 beta 版。 紧急情况：如果Bug比较紧急可跳过一般流程，由开发人员尽快修复Bug，测试确认之后直接发布该版本的 beta版。 5. 5 5 .版本号修改举例说明 如此时版本号为：1.0.0.0321_alpha ，此时为内部测试阶段 （1）开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： 1.0.0.0321_beta ，如当前日期跟上一个版本号的日期不一样，版本号可改 为：1.0.0.0322_beta。 （2）如果修复了一些重大Bug 并按照流程发布到外网时就可发布一个修订版，如1.0.1.0322_beta，日期为发布的当前日期。
技术服务规范 为了协调公司各部门工作，更好地为客户服务，我们根据弱电安防行业标准制定了以下作业程序，使之成为公司规范化管理的标准。 一、工程承接 公司业务部人员在接到用户委托后，协同系统工程部，根据用户要求、风险等级标准进行实地测试，查看现场，根据中华人民共和国公共安全行业标准等有关规定，制订科学可行的工程方案设计书、绘制施工图、编制概（预）算。 设计方案经行业主管部门、用户单位论证确定后，依法签定包括售后服务内容在内的工程承包合同。 二、工程施工 合同签定后，工程管理部将严格按照合同确定的施工日期，派出由项目经理及工程技术人员组成的项目部。项目部根据施工图纸，确定施工方案，及时向工程土建单位出具施工联系单。参与现场施工的所有施工人员，应严格遵守行业的施工规定与要求安全施工。工程人员应严格遵守企业保密制度，着工作服，带好有关证件，保质保量地在规定时间内完成施工。施工过程中若方案有新的变动，需经用户方同意，并填报“工程联系单”书面确认；交工前要予以验收。 三、工程验收
整个工程按合同书内容操作完成后，项目部应及时填报工程试运行报告、竣工报告，绘制工程竣工图。试运行结束前会同行业主管部门、用户单位进行工程验收，并根据验收情况开展需求的整改工作。工程复验后多余器材和辅料及时退库，按复验结果出具工程决算清单和绘制竣工图。并按系统使用要求对用户单位人员提供免费技术培训。 四、工程资料移交和存档 工程复验竣工后，项目部应将有关工程资料严格按照行业规定设定密级并统一交公司办公室存档。存档内容：（1）工程设计方案（包括初案）；（2）合同；（3）器材清单（预、决算书）；（4）平面布置图；（5）竣工图；（6）工程验收单；（7）工程联系单。 工程竣工后，工程管理部需将有关工程方案、合同、图纸整套移交给售后服务部并办理移交手续，填写"工程资料移交单"。所有移交手续资料报公司办公室备案。 五、售后服务 售后服务部在工程交接后，应严格遵守工程合同的保修、维修约定条款，以及本公司的售后服务承诺：对竣工工程保修期内每月一次巡访，维修响应时间为30分钟以内，维修工程师于市内2小时、市外4小时内赶赴现场。维修完毕后将"维修单"交用户签字，一式二份，一份交用户，另一份交回公司办公室决算和存档。
海运出口流程 大概流程： 订舱→检查SO→跟客户确认装柜时间，安排拖车（发SO和派车单给车行）→装柜→还柜后报关→截关当天提交补料→核对提单等资料→申请付款 具体操作 一、订舱 1：发货人根据贸易合同或信用证条款的规定，在货物托运之前一定时间内，填制订舱单，向船公司或者货运代理公司申请订舱。 2：出口货物代理委托书（委托书、订舱单），如果被委托方无法接受或满足委托书上的某些要求，被委托方要及时作出反应，以免耽误船期。 3：委托书内容： ①收货人、通知人、商品名称（中英文）。唛头、件数、包装、毛重、尺码、起运港、目的港、中转港、装运期限、配载要求、货物交运日期以及交运方式、可否分批装运；集装箱类别、数量以及装箱或提箱要求；运费结算方式（预付、到付金额） ②其他特殊事项：例如危险品、冷冻货的特殊说明 ③提单记载事项：提单发货人、收货人、通知人、正本份数以及信用证要求。 二、检查SO 收到船公司或者货运代理公司的SO后，仔细检查SO上的内容（柜型、柜量、截关时间、起运港、目的港、中转港） 三、派车及装柜 最少要提前一天把SO和派车单给到车行，车行要在一定时间内换好提柜单。在装柜前天下午三点前之前就要把SO给到车行去换单，以免换单出现问题，好在船公司下班前能够得到及时的解决。 按发货人的要求，通知拖车公司按时拖柜到指定地点装柜，并在上柜期间及时跟踪上柜情况。 如果遇到提不到柜，或未能及时按照客户要求到达工厂的，及时与船东和堆场联系并跟工厂打好招呼。货柜到达后，由发货人自行安排工人装柜，装完柜封好封条后，再由拖车公司负责将货柜运送至码头。 四、报关 1：一般情况下，发货人提供的报关资料是装箱清单（包柜），正常退税的话，就要提供装箱单，发票，合同，报关关，报关委托书 2：报关时间应在还柜后，船开前两天至三天。 3：报关行凭发货人所提供的资料进行报关 五提单补料 1：“提单”是指一种用以证明海上货物运输合同和货物由承运人接管或装船， 以及承运人据以保证交付货物的单证。它是收货人提货的凭证。 2：提单内容 ①?船名航次 ②?提单号 ③?承运人名称 ④?发货人 ⑤?收货人 ⑥?通知人 ⑦?装货港、卸货港、转运港 ⑧?货物的名称、标志、包装、件数、重量、体积 ——仅供参考
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
1．服务级别及响应方式 在系统建设中我部门将提供优良的服务和技术支持。一旦系统出现硬件、软件、网络故障，不能正常工作，本部门提供以小时和工作日为单位的响应服务。 2．服务范围 硬件设备：包括把系统恢复到正常工作状态所需要的所有零部件 软件维护：包括把软件恢复到正常工作状态所需要的所有软件应用 网络：诊断与排查网络故障与优化网络 3．服务方式 员工碰到任何问题，可先通过电话与专人联系，寻求技术支持。 电话——员工可在星期一至星期五，8：00-17：00期间获得电话支持； 远程拨入——网络工程师可以通过远程网络拨入，远程检查你的系统，以便更快捷的解决问题。 现场——如果有些问题不能通过电话或远程拨入解决，我部门将派遣经验丰富的网络工程师，到现场为您服务。 4．紧急程度 A级——严重，系统无法使用 B级——紧急，系统遭到严重破坏 C级——一般，有问题但不太严重 5．服务级别 服务级别分为：一级、二级 6．响应时间
响应时间是根据我部门所提供的不同服务级别来确定，具体见下： 一级服务：响应紧急程度A，B级 电话支持:7*24，指的是员工每周7天，从周一至周日，8小时工作时间内外（0点至24点），每天24小时可要求我部门提供服务。 现场支持:我部门接到服务请求经过确诊后，工程师2小时之内到达现场进行维 修；直至原主机恢复到正常状态。 非工作时间远程支持：网络工程师可以通过远程网络拨入，远程检查你的系统，以便更快捷的解决问题。非工作时间（如：深夜，周末与节假日等）如遇本地主机系统崩溃或系统遭到严重破坏，我部门将立即通知供应商实施现场支持。 二级服务：响应紧急程度C级 电话支持:5*8，指的是员工每周5天，从周一至周五，8小时工作时间以内（早8点至下午5点），每天8小时可要求我部门提供服务。 远程拨入——网络工程师可以通过远程网络拨入，远程检查你的系统，以便更快捷的解决问题。 现场支持:我部门接到服务请求经过确诊后，工程师4小时之内到达员工现场进行维 修；直至原主机恢复到正常状态。 7．每年度一次的技术支持总结 通过对员工请求和相应服务跟踪报告的分析，总结技术支持的工作效率和问题提高技术支持的水平和质量，总结员工在使用设备与系统时发现的问题和需求，返回给技术部门；使我们提供给员工的设备更能符合员工的要求。 8. 技术顾问服务
报关；就是发货人把出口的货物的相关资料向当地海关申报，海关审核后出放行条给运输公司，运输公司收到放行条才有资格把运输货物出境，出去的时候才有报关，进来的时候叫清关。 清关；清关和报关刚刚相反，就是收货人把进口的货物的相关资料向当地海关申报，海关审核后出放行条给运输公司，运输公司收到放行条才有资格把运输货物进境，出去的时候才有报关，进来的时候叫清关。 封关；异地海关用于海关内部联系、交接有关单证所使用的印有“海关关封”字样，可以加封的信封，不可以私自拆开 注意 封关是随着转关同时出现的，刚才那个例子，货物从东莞报关，转关到深圳发往美国，在东莞报关完毕后，会把东莞报关完毕的资料放在一个信封里面，这个信封不准私自拆开交给海关，还有运输的货物从东莞到深圳的途中不允许私自拆开跟换或落地，必须在监管车辆的监管下运输，一旦货物落地或拆开，视同拆关。 拆关；就是在海关在异地海关监管仓库把封好关的车进行拆关,也就是把封条拆掉. 截关；也叫截放行条时间，是指截止报关放行的时间，货物必须要在此时间之前做好报关放行的工作，递交海关放行条给船公司。 注意； 出口的货物进入到指定地点后，等待发货人在规定的时间内向海关报关，在规定的时间内报关完毕货物才可以被运输公司运往国外，假如在规定的时间内报关没有完成，船或飞机要开了，运输公司也没有资格把这个货物运到国外。截关就是一个时间点，必须在这个时间之前完成申报工作得到放行的指令。 结关；是指对经口岸放行后仍需继续实施管理的货物，海关在固定的期限内进行核查，对需要补证、补税货物作出处理直至完全结束海关监管的工作程序。 转厂；两个外资加工贸易企业A和B在国内将A生产的产品直接卖给B的一种国内贸易形式，结算都在境外通过外汇安排，但是交易是在国内完成。 eg.某东莞公司和宝安公司都是来料加工，东莞公司生产的成品如电阻要卖给宝安公司做料件，以往办理这种跨关区的“转厂”，手续很繁琐。现在他们选择了保税区后一切都变得简单了：东莞公司办理东莞至福保的出口转关交货至保税区视同出境，再用宝安公司的进口报关单办理货物的进口手续，货物的运输都是由国内车辆完成，省钱省心。
APP版本命名规范 2016/11/18 ALEX 1.版本号构成说明 APP版本号由四部分组成，中间用英文字符“.”连接。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号加希腊字母版本号。版本号为阿拉伯数字0-9，希腊字母版本号共有五种，分别为base、alpha、beta、RC、release。 举例：V1.2.3.20161118.beta。其中1代表主版本号，2代表次版本号，3代表修订版本号，20161118代表日期版本号，beta代表希腊字母版本号。 2.APP版本阶段说明 A.Base：此版本表示该APP仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是 页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。 B.Alpha：APP的测试版本。该APP在此阶段以实现功能为主，通常只在APP开发者内部交 流。一般而言，该版本bug较多，需要继续修改。测试人员提交bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将APP版本标注为alpha版。 C.Beta：该版本相对于Alpha版已经有了很大的进步，消除了严重错误，但还需要经过多次 测试来进一步消除，此版本主要的修改对象是APP的UI。修改的的bug经测试人员测试确认后可发布到外网上，此时可将APP版本标注为beta版。 D.RC：该版本已经相当成熟，基本上不存在导致错误的bug，与正式版本相差无几。 E.Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式 的版本，是最终交付用户使用的一个版本。该版本有时也称标准版。 3.版本号修改规则 初始版本号：V1.0.0.20161117.alpha，此时为内部测试阶段。 A.希腊字母版本号：此版本号用于标注当前版本APP处于哪个开发阶段，当APP进入到另一 个阶段时需要修改此版本号。此版本号由项目决定是否修改。
技术服务管理制度 技术服务管理制度 第一章总则 第一条适用范围
本管理办法适用于中国建筑标准设计研究所发行室(以下简称发行室)。 第二条目的 主要经过技术服务来扩大标准所的市场知名度,塑造品牌形象以及增强国标的权威性。 第三条原则 原则上,发行室不能把技术服务作为年度创收的渠道或盈利来源,而应作为走向市场,实现年度销售目标的一种营销策略。 第二章技术服务的组织管理 第四条技术服务方案制定 技术服务方案制定由营销主管负责组织制定,经主任审批和主任办公会讨论经过后,上报标准所主管领导审核,审核经过后,由有关部门负责执行 第五条技术服务方案执行 营销主管负责技术服务方案的组织实施 第六条技术服务方案实施过程监督 营销主管领导负责对技术服务执行过程进行监督检查 第七条技术服务实施效果考核 主任负责对技术服务方案执行效果进行考核
第三章技术服务形式 第八条技术服务形式或内容 (一)技术培训会 (二)标准化技术研讨会 (三)技术推广会 第四章技术培训 第九条培训主题 培训主题根据客户需求和现有技术专家资源情况而决定。 第十条培训对象 设计院、建筑工程、房地产开发等单位的工程技术人员。 第十一条培训时间 一般确定为春季、秋季各一次。 第十二条参会人数 由营销管理根据客户培训需求调查统计分析而制定。每次会议不得低于办会成本标准为原则。 第十三条收费标准 首先由营销管理根据培训内容、培训专家资质水平、参会人数、办会环境等因素而拟订会议收费标准,报主管领导审核,主任和主管所长审批后执行。 第十四条会议运作管理 (一)会前准备
负责联系培训专家、课程安排,确定培训地点、时间、住宿标准、相关培训材料的准备及其它相关服务工作等。 (二)会议组织 1.会前签到 营销主管组织相关人员给与会人员办理签到手续、住宿登记、日程安排、有关资料发放等 2.会中组织 (1)为授课老师作好服务; (2)为与会人员作好服务。 参会、就餐、娱乐、休息、预定火车票或飞机票等 3.会后服务 (1)培训效果调查:当培训会结束的后,营销主管将事先设计好的技术培训效果调查表发放给与会人员,并在问卷发放后的1个小时内进行回收,调查问卷回收率不得低于参会人员的98%。 (2)疏散参会人员离开宾馆。 (3)营销主管协助有关人员(主任/财务)与宾馆进行结算。 第十五条会后总结 会议结束之后,营销主管负责写技术培训分析报告,总结本次会议成功的的经验和成功或失败的关键因素分析以及本次办会的宗旨和目的是否达到,现存的主要问题、未来改进的措施和方法等。
船务单证资料汇总一：船务流程 下BOOKING-催要S/O-凭S/O安排拖车提柜-做柜-还柜-报关-放行-提供补料-对单-DEBIT NOTE–付Forwarder费用-收提单-催收核销单 1、客人把订单下到公司，经公司各部门的产能评估后，作出的生产日期和出货日期的安排。 2、船务部接到业务部下达的订单后，根据订单出货日期录入出货排程。2.按PO 数量排柜 按可以拼柜的货算出总材积再分别看能装多少个柜，什么柜型？ 一般货柜有20’GP--（L）591*（W）234*（H）238CM=32.91CBM 40’GP--（L）1204*（W）234*（H）238CM=67.05 CBM 40’HQ--（L）1204*（W）234*（H）268CM=75.50 CBM 45HQ--（L）1360*（W）234*（H）268CM=85.28 CBM 以上为理论尺寸,即完全没有空隙的地方,实际因为箱子的大小不同,不可能装柜率达到100% 一般货柜实际尺寸为 20’GP-----28CBM 40’GP-----50~53CBM 40’HQ-----60~65CBM 45’HQ-----68~72CBM (PO----Purchase Order 采购订单, 长X宽X高（米）=CBM 长X宽X高(inch英寸)/1728/35.315=CBM 1inch=2.54CM 3.BOOKING(订舱) BOOKING 一般做FOB的客户都会指定它的货代来帮他出货，不同的客户向不同的货代订舱，现在网络通讯发达，一些比较大的货代要求客户在网上系统中订舱。比如马士基（MEARSK）要求在MPS上订舱，NKY要求在它的NYK E-BOOKING 上进行订舱。 其他的小公司一般要求填写他们公司的BOOKING FORM。然后E-MAIL或传真给它就行。BOOKING需填写的内容有：SHIPPER（出货人），CONSIGNEE（收货人）NOTIFY（通知人）；PORT OF LOADING（装运港）PLACE OF RECEIP（收货地）；PORT OF DISCHARGE （目的港），MARKS & NUMBERS 唛头；NO OF PKGS（件数）DESCRIPTION OF GOODS （产品描述）KG （总重）CBM （总材积） 若付款条件是L/C是话，以上内容必须跟L/C 一致，（最好大小写，标点符号也一致） 还要在FREIGHT PERPAID （预付）或FREIGHT COLLECT （到付）后面打个V，DOCUMENT REQUIRED 后面选择是文件要出B/L，还是FCR形式的提单。（B/L 表示BILL OF LOAD，FCR 表示FORW ARDER CARGO RECEIPT，二者都叫提单，这要看L/C 上
软件项目版本号的命名规则及格式介绍 版本控制比较普遍的3种命名格式: 一、GNU风格的版本号命名格式: 主版本号.子版本号[.修正版本号[.编译版本号]] 英文对 照:Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Numb er]] 示例:1.2.1,2.0,5.0.0build-13124 二、Windows风格的版本号命名格式: 主版本号.子版本号[修正版本号[.编译版本号]] 英文对 照:Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Numb er]] 示例:1.21,2.0 三、.NetFramework风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] 英文对 照:Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Numb er]]
版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订 号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果 定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于 或等于0的整数。 应根据下面的约定使用这些部分： Major：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于 对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示 显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后 兼容的新版本。 Build：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处 理器、平台或编译器的情况。 Revision：名称、主版本号和次版本号都相同但修订号不同的程序集应是完 全可互换的。这适用于修复以前发布的程序集中的安全漏洞。 程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修 补程序(Hotfix)更新。 版本号管理策略 一、GNU风格的版本号管理策略： 1．项目初版本时,版本号可以为0.1或0.1.0,也可以为1.0或1.0.0,如果你为人很低调,我想你会选择那个主版本号为0的方式;
1总则 1.1为规范公司技术服务费和评审费的管理，根据国家相关法律、法规及集团公司有关规定，结合公司实际情况制定本办法。 1.2本办法所称技术服务费是指公司在生产经营过程中，支付有关单位或个人为公司提供与工艺、技术有关的指导、服务而发生的费用。 本办法所称评审费是指为设计联络会、产品验收会、管理项目验收会（认证会）等聘请专家发生的评审费用等。 1.3本办法适用于公司各部门。子公司参照执行。 2 费用涵盖范围 2.1技术服务费涵盖范围 2.1.1有关单位或个人为公司的工程建设项目、技术改造项目和技术引进项目提供相关技术指导和服务发生的费用。 2.1.2有关单位或个人为公司产品工艺和生产流程提供的指导和服务发生的费用。 2.1.3有关单位或个人为公司研发项目提供的指导和服务发生的费用。 2.2评审费涵盖范围 2.2.1有关单位或个人为公司项目设计联络会、产品验收会、管理项目验收会（认证会）等聘请专家发生的费用。包括为项目进行符合性鉴定（如：加计扣除）而聘请有权的专家等发生的费用。 3操作流程 3.1技术服务应当签订纸质协议，协议应包括需要技术服务的原因、服务内容和
支付标准，原则上一个项目一签。 3.2技术服务应当对每次提供服务做出书面记录，包括：时间、地点、参与人员，服务内容。 3.3技术服务应当在每次提供服务后出具小结，对服务的内容和产生的效果做出文字描述。 3.4技术服务应当在一个合同周期（一般为一年）结束时对服务提供方做出总结性的书面评价（应包括服务效果的验证和续不续签合同的原因的描述）。 3.5效果是指本办法第2条所述项目接受技术指导和服务产生的效益和成果，可以是项目因接受技术服务而产生的时间效益、资金效益等利益，或者是最终形成专利、专有技术等知识产权成果。 3.6评审费应有评审原因（有文件规定的提供文件，无文件规定的提供书面报告）、评审过程记录（比如：会议通知，签到记录；鉴定费也如此）、载有评审（或鉴定）结果的文件。 4支付 4.1技术服务协议的签订部门应根据合同进度支付技术服务费，审批流程按照公司《资金计划管理办法》的规定执行，支付时应提供协议、服务记录、小结（或总结）、发票（如是个人，提供签领记录并代扣代缴个人所得税）或其他完税凭证。 4.2评审费（或鉴定费）的支付审批流程按照公司《资金计划管理办法》的规定执行，发生部门应在费用报销时提供第3条3.6款所述资料和发票（如是个人，提供签领记录并代扣代缴个人所得税）或其他完税凭证。
项目软件版本号管理规范
历史修改记录 一. 目的
1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象， 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一 管理。 1.3本文档是为规范研发部软件版本管理而制定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号：内部版本号和外部版本号。版本号使用 VP规则，V(Version)是指外部版本号（研发测试版本），P(Patch)是指补丁版本号（可选）。 3.1.2版本号命名：V/B+主版本号+次版本号+修订版本号+日期版本号
3.2版本号修改规则 3.2.1主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生 变化。此版本号由项目决定是否修改。 3.2.2次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变 动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩 充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要 更改日期版本号。此版本号由开发人员决定是否修改。 如： V8.1.0.XXX (上一级版本号有变动时，下级要归零) 3.3版本号修改举例说明 如此时版本号为：V8.1.0.XXX ，此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： V8.1.1.XXXX ，如当前日期跟上一个版本号的日期不一样，版本号可改为： V8.1.1.XXX。
船公司SO文件和集装箱上的英语 截关（closing date),也叫截放行条时间，是指截止报关放行的时间，货物必须要在此时间之前做好报关放行的工作，递交海关放行条给船公司。 “结关日”就是大家常说的“截关日”，而且这个说法主要在宁波或者广东那里比较流行。截关含义 在此时间之后再递交海关放行条，船公司将视该货物未能清关放行，不允许上船。一般是船开日前1-2天（散货是提前5-7天），而且一般是在截港时间后半个工作日。 Reefer Tetails:冷柜参数 contact：联络人,联系方式 contact person：联络人 intended fcl container delivery CUT-OFF：指定的重柜交柜时间，装箱整箱交付截止 intended shipping instruction CUT-OFF：指定的文件结关时间，航运指示截止 DOC CUT-OFF：文件结关时间(可能没有额外指定,按船公司一般的规律) 像上面都是有特指的） Cargo nature：货物种类 service contract NO：服务合同编号， SI CUT: 截提单补料或截关 BKG Staff: BKG是Booking的简写，那就是订舱人员 Regional BKG#:预订区域， Sales Rep: 销售代表 BILL of Lading#:提单号，提单方案 Empty Pick up CY:提空柜地点 Empty Pick up Date:提空柜时间，提柜有效期 Pre Carrier: 预载 Est.ArrivalDate:EIS到达时间 CY CUT: 结关时间（具体还不清楚是码头截重柜还是截海关放行条时间） CY open: 整柜开仓时间 Port of delivery：交货港口 Receive Term: 接收期限 Delivery Term: 交货期限 Ocean Route Type: 海运路线类型，多指印度洋航线类型 EQ Type/Q＇ty:集装箱数量，类型EQ是Equipment的简写 Address:地址 Special cargo information: 特别货物信息
软件项目版本号的命名规则及格式 版本控制比较普遍的3 种命名格式: 一、GNU 风格的版本号命名格式: 主版本号 . 子版本号[. 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Nu mber]] 示例: 1.2.1, 2.0, 5.0.0 build-13124 二、Windows 风格的版本号命名格式: 主版本号 . 子版本号[ 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Nu mber]] 示例: 1.21, 2.0 三、.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Nu mber]] 版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于或等于0 的整数。 应根据下面的约定使用这些部分： Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。 Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。 程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序(Hotfix) 更新。 版本号管理策略 一、GNU 风格的版本号管理策略：
计划生育技术服务质量 管理规范 公司标准化编码 [QQX96QT-XQQB89Q8-NQQJ6Q8-MQM9N]
计划生育技术服务质量管理规范 第一章总则 1．为了加强计划生育技术服务质量管理，规范计划生育技术服务行为，提高技术服务质量和水平，为人民群众提供优质、安全、满意的计划生育技术服务，根据《中华人民共和国人口与计划生育法》、《计划生育技术服务管理条例》等法律、法规及有关规定，制定计划生育技术服务质量管理规范。 2．计划生育技术服务要坚持安全第一、质量第一的方针。坚持以人为本，以服务对象为中心，遵循国家相关法律、法规。 3．计划生育技术服务质量规范管理目标是规范计划生育技术服务，提高计划生育技术服务质量，提升计划生育技术服务管理水平，保障服务对象的身心健康与生命安全。 4．计划生育技术服务机构和技术人员向服务对象提供服务时，必须保障服务对象的计划生育生殖健康权益，保障服务对象获得国家规定的免费技术服务，满足服务对象计划生育生殖健康及相关方面的需求。 5．本规范是各级计划生育技术服务机构开展计划生育技术服务工作和技术服务质量管理的基本要求和行为准则。 第二章质量管理基本要求 1．计划生育技术服务质量规范管理包括机构管理、人力资源管理、基础设施管理、器械仪器设备管理、药品和避孕药具管理、技术服务过程管理、技术服务文书档案管理、环境安全管理和质量管理持续改进等。 2．计划生育技术服务机构应设立技术服务质量管理组织，配备技术服务质量管理人员，制定技术服务质量管理制度，建立技术服务质量管理机制。计划生育技术服务机构应逐步引入现代质量管理方法，创新计划生育优质服务理念。 3．计划生育技术服务机构的法定代表人是技术服务质量管理的第一责任人，负责本机构技术服务质量管理组织的建立和质量管理标准、规范的组织实施。各部门和各岗位人员是本机构实施全面质量管理的重要成员，是技术服务质量管理规范的实施者。
软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书
需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划 上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。
配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目内部的目录结构： |–projectA
物流基本操作流程 1.接受客人委托，仔细审单，按照客人提供的货物备好时间和船公司船期合理安排订舱。 2.向船公司下订舱委托（样本货代公司已提供贵司）。 第三步操作（装箱环节）分四种情况，我用A B C D标明： A:3.船公司确认货代公司订舱并按照船期在合适的时间回传货代公司提箱单（提箱单各个船公司不一样，但大致信息如：船名航次提单号箱型箱量开航日提箱地等都有）4.和客人核实具体装箱日期及装箱地址，联系车队（运费价格事前已谈好）给车队发提箱单和装箱明细同时给客人发配载信息。 5.车队按照装箱时间合理安排去提箱单指定堆场提箱，提箱后把箱号铅封号司机电话车牌号等信息发给货代公司。货代公司收到后将这些信息及时提供给客人。 6.在预先安排好的装箱时间，车辆到厂装箱，装箱完毕后卡封回港。 7.车辆回港后，按照船公司规定落重箱到指定堆场，而后堆场向海关发送运抵报告。 B:3.船公司确认货代公司订舱，若客人做送货到堆场的，则货代公司要求船公司传真货代公司送货通知。（送货通知上大致信息有船名航次提单号开航日送货地址等信息）货代公司用货代公司固定格式给客人发送货通知。 4.在货代公司指定的时间内客人将货物送到指定堆场，堆场装箱完毕后卡封并将箱号铅封号反馈货代公司同时堆场向海关发送运抵报告。 C:3.船公司确认货代公司订舱，若客人做自提自装自集（及俗称三自）货代公司收到船公司提箱单后直接将提箱单传给客人同时标明报箱号时间、是否需要运抵报关或集太平洋。 4.在货代公司指定时间内客人提供箱号铅封号给货代公司，货代公司提供给船公司即可。D:3.船公司确认货代公司订舱，客人是做送货的，但是货代公司订舱的船代处无法提供送货地址或者他们收费较高的话，我们会向订舱公司要提箱单传外贸公司，外贸公司自行找堆场装箱。此种做法需事先联系好堆场，谈好费用，待提箱单传给货代公司后，货代公司先将提箱单传给所找堆场并随附传他装箱明细，他在货代公司指定时间内去提箱并将箱号封号反馈货代公司。货代公司在给堆场发提箱单的同时参照提箱单上的船名提单号等信息给客人发货代公司所找堆场的地址。 4.在货代公司指定时间内客人将货物送到货代公司指定堆场装箱完毕后堆场发送运抵报告给海关。
软件版本管理规 V1.0.0 文档版本变更记录：
目录 前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)
前言 为规部门产品软件版本的管理与控制，保证产品版本的有效与质量，制定本标准。本标准由移动金融事业部拟制。 本标准于2015年6月首次发布。
软件版本管理规定 1围 本标准规定了移动银行事业部产品软件版本的控制与管理。 本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义 下列定义适用于本标准。 2.1软件 指与产品相关的所有软件，可以分为产品软件和演示软件。 2.2产品软件 已签订合同，有明确交付日期的产品。 2.3演示软件 处于研发阶段，并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成 产品的正式软件版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 产品的演示版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 3.2产品软件版本命名 产品软件版本的命名规则如下所示：