版本号

Mac安装指定版本的node 安装Homebrew Homebrew是一款Mac OS平台下的软件包管理工具，拥有安装、卸载、更新、查看、搜索等很多实用的功能。简单的一条指令，就可以实现包管理，而不用你关心各种依赖和文件路径的情况，十分方便快捷。 在终端上运行 $ /usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)” 安装完成后运行 $ brew -v 出现版本号则说明安装成功 安装nvm nvm是node版本管理工具，为了解决node各种版本存在不兼容现象，nvm是让你在同一台机器上安装和切换不同版本的node的工具。 安装nvm $ brew install nvm 安装完成后打开shell的配置文件 $ cd ~ $ vim .bash_profile 按 i 进入编辑模式 在文件里添加以下命令 export NVM_DIR=~/.nvm source $(brew --prefix nvm)/nvm.sh 然后按esc退出编辑模式 按 :wq保存 重新source $ source .bash_profile 安装node指定版本 查看所有的node可用版本 $ nvm Is-remote 下载指定版本 $ nvm install

安卓sdk版本号与手机对应版本号 获取最新版本号,可通过谷歌网站 https://developer.android.google.cn/about 获取,只对现有版本号进行排版. 平台版本 SDK版本 版本名称 9.0 28 Pie (Android P) 8.1 27 Oreo(Android O)（奥利奥） 8.0 26 Oreo(Android O)（奥利奥） 7.1 25 Nougat(Android N)（牛轧糖） 7.0 24 Nougat(Android N)（牛轧糖） 6.0 23 Marshmallow(Android M)（棉花糖） 5.1 22 Lollipop(Android L)（棒棒糖） 5.0 21 Lollipop(Android L)（棒棒糖） 4.4 19 KITKAT（奇巧巧克力） 4.3 18 JELLY_BEAN_MR2(果冻豆) 4.2/4.2.2 17 JELLY_BEAN_MR1(果冻豆) 4.1/4.1.1 16 JELLY_BEAN(果冻豆) 4.0.3/4.0.4 15 ICE_CREAM_SANDWICH_MR1(冰激凌三明治) 4.0/4.0.1/4.0.2 14 ICE_CREAM_SANDWICH(冰激凌三明治) 一般市场上主流版本号都会较最新版本第两个版本. 来源： oschina 链接： https://my

Linux的历史 　　 1991年，芬兰大学生开发了一个类Unix系统，这个系统就是Linux系统。 　　1994年，Linux加入GNU计划并采用GPL协议发布。从此之后，GNU/Linux真正实现了构建一套完全自由的操作系统的思想。 Linux内核版本 　　XX YY ZZ 　　XX：表示主版本号 YY：表示次版本号(奇数表示开发板，偶数表示稳定版) ZZ：表示末版本号 Linux系统安装 　　 VMWare Workstation Pro、CentOS(64位) 常见网络模式：1.桥接模式2.NAT模式3.仅主机模式 　　桥接模式：虚拟机和物理机连的是同一个网络，虚拟机与物理机是并列关系，地位相当。举例而言：手机和电脑能够同时连接家里路由器提供的Wi-Fi。 　　NAT模式：物理机充当“路由器”角色，虚拟机想要上网，必须经过物理机。这种模式兼容性最好，这是因为当物理机的网络环境变化时，虚拟机网络并不会有影响。 　　仅主机模式：相当于拿一根网线直接连了物理机和虚拟机。 划分磁盘分区规则 　　（1）/boot分区200MB 　　（2）swap分区分内存的2倍（如果内存大于4GB，swap分8GB即可） 　　（3）/分区分20GB 　　（4）剩余的空间给/data分区 tips: 　　启动Centos时，报错，原因是启动VMWare时，没有以管理员的身份启动。 　　 　　 --

CAS操作是计算机底层的操作，对于内存中的某一个值V，提供一个旧值A和一个新值B，如果提供的旧值V和A相等就把B写入V，CAS操作是基于底层命令的，是原子性的操作 CAS在可以作为乐观锁的使用，每次操作不加锁，假设没有冲突，如果因为冲突失败就重试，直到成功为止 Java对CAS提供了很好的支持，如AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference等 CAS中存在一个经典的问题，即ABA问题：如果另一个线程修改V值假设原来是A，先修改成B，再修改回成A。当前线程的CAS操作无法分辨当前V值是否发生过变化 而对于ABA问题，Java也提供了很好的解决方案，AtomicStampedReference AtomicStampedReference在内部维护了一个Pair类，除了存储Reference外，也存储了当前数据对应的版本号，在执行compareAndSet方法时，会判断版本号是否一致，如果版本号不一致，则说明Reference已经发生过变化，在执行CAS操作时，实际更新的是Pair对象，因此Reference和版本号是同时原子更新的 Java同时提供了一个AtomicMarkableReference类，AtomicMarkableReference与AtomicStampedReference的API类似

版本控制比较普遍的 3 种命名格式 : 一、GNU 风格的版本号命名格式 : 主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]] 示例 : 1.2.1, 2.0, 5.0.0 build-13124 二、Windows 风格的版本号命名格式 : 主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]] Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]] 示例: 1.21, 2.0 三、.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]] 版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的； 内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。 所有定义的部分都必须是大于或等于 0 的整数。 应根据下面的约定使用这些部分： Major

1.概述 每个项目的根目录下面，一般都有一个 package.json 文件，定义了这个项目所需要的各种模块，以及项目的配置信息（比如名称、版本、许可证等元数据）。 npm install 命令根据这个配置文件，自动下载所需的模块，也就是配置项目所需的运行和开发环境。 package.json 文件内部就是一个JSON对象，该对象的每一个成员就是当前项目的一项设置。比如 name 就是项目名称， version 是版本（遵守“大版本.次要版本.小版本”的格式） 2.scripts 字段 scripts 指定了运行脚本命令的npm命令行缩写，比如start指定了运行 npm run start 时，所要执行的命令。 3.dependencies 字段和 devDependencies 字段 { "devDependencies": { "browserify": "~13.0.0", "karma-browserify": "~5.0.1" } } 指定版本：比如 1.2.2 ，遵循“大版本.次要版本.小版本”的格式规定，安装时只安装指定版本。 波浪号（tilde）+指定版本：比如 ~1.2.2 ，表示安装1.2.x的最新版本（不低于1.2.2），但是不安装1.3.x，也就是说安装时不改变大版本号和次要版本号。 插入号（caret）+指定版本：比如ˆ1.2.2，表示安装1.x

1.处理冲突 当使用 index API更新文档的时候，我们读取原始文档，做修改，然后将整个文档(whole document)一次性重新索引。 最近的索引请求会生效——Elasticsearch中只存储最后被索引的任何文档。如果其他人同时也修改了这个文档，他们的修改将会丢失。 很多时候，这不是问题。 也许我们的主数据存储是关系数据库，我们只是将数据复制到Elasticsearch中以使其可搜索。 也许两个人几乎不可能同时更改同一个文档。 或者，如果偶尔失去变化，对我们的业务来说也许并不重要。 但有时失去变化 非常重要 。 想象一下，我们正在使用Elasticsearch来存储我们在线商店中库存的小部件数量。 每次我们出售小部件时，我们都会减少Elasticsearch中的库存数量。 有一天，管理层决定进行销售。 突然间，我们每秒都在销售几个小部件。 想象一下，两个并行运行的Web进程，每个进程都处理一个小部件的销售，如下图显示没有并发控制的结果 。 　　 在数据库领域，通常使用两种方法来确保在并发更新时不会丢失更改 ： 悲观的并发控制 这种方法广泛用于关系数据库，它假定可能发生冲突的更改，因此阻止对资源的并发访问以防止冲突。 一个典型的例子是在读取数据之前锁定一行，确保只有放置锁的线程才能对该行中的数据进行更改。 乐观的并发控制 由Elasticsearch使用，

近期困惑于Git代码版本控制，集中两天时间研究，其中基础知识来源于《Git权威指南》，分支思想则来源于一篇博文《A successful Git branching model》（作者：Vincent Driessen，原文链接： http://nvie.com/posts/a-successful-git-branching-model/ ），细读之下，受益匪浅，仅于此文记录心得，详细内容请参考原文。 Main Branch master 主分支，代表着部署（生产）环境最新版本的代码状态，即代码始终与部署环境最新版本代码保持一致； develop 开发分支，代表着即将发布的下一个版本的代码状态；也可以理解为“整合”分支，开发新特性或修复Bug过程中产生的新代码需要定期合并至开发分支，用于“每日”构建。 当开发分支（develop）中的代码稳定到一个可发布的状态时，需要被合并至主分支（master），由主分支创建相应版本（Tag）。 Supporting Branch Feature 特性分支，用于开发新的功能特性，生命周期如下： （1）需要开发新的功能特性时，从开发分支创建一个或多个特性分支； git checkout -b myfeature develop （2）新的功能特性开发完成时，特性分支需要合并至开发分支； git checkout develop git merge

在使用maven过程中，我们在开发阶段经常性的会有很多公共库处于不稳定状态，随时需要修改并发布，可能一天就要发布一次，遇到bug时，甚至一天要发布N次。我们知道，maven的依赖管理是基于版本管理的，对于发布状态的artifact，如果版本号相同，即使我们内部的镜像服务器上的组件比本地新，maven也不会主动下载的。如果我们在开发阶段都是基于正式发布版本来做依赖管理，那么遇到这个问题，就需要升级组件的版本号，可这样就明显不符合要求和实际情况了。但是，如果是基于快照版本，那么问题就自热而然的解决了，而maven已经为我们准备好了这一切。 maven中的仓库分为两种，snapshot快照仓库和release发布仓库。snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。定义一个组件/模块为快照版本，只需要在pom文件中在该模块的版本号后加上-SNAPSHOT即可(注意这里必须是大写)，如下： <groupId>com.zang.rc</groupId> <artifactId>registry</artifactId> <version>2.0.0-SNAPSHOT</version> maven会根据模块的版本号(pom文件中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。如果是快照版本，那么在mvn

提交代码导致冲突，执行merge后，冲掉其他人的提交。需要reset，并新建分支进行恢复解决方法： 1.找到最后一次提交到master分支的版本号，即【merge前的版本号】 2.会退到某个版本号 git reset --hard 【merge前的版本号】 这个时候已经会退到了上一次提交的版本，但是之后的修改还是存在master分支上，以下步骤很关键 3.重新创建一个分支,这时候的分支就是上一次提交的代码 git checkout -b newmaster 4.推到对应的远程newmaster git push 5.这个时候相当于备份做好了，接下来就可以删除本地及远端的master分支 git branch -d master git push --delete origin master 6.从newmaster分支，重新在创建master分支，并推向远端 git checkout -b master git push7.大功告成！ 来源： https://www.cnblogs.com/shuimuzhushui/p/10893551.html