Maven のバージョン番号 version の概要と理解
この記事の目的
前回の記事に引き続き、maven の基本概念の紹介と、mavenその中の坐标と の概念についての一般的な理解を説明します仓库。その中にバージョン番号というラベルが坐标あるのですが、このラベルの機能については非常に重要だと思うので、別途私の理解をまとめておきます。プロジェクト に取り組んでいると、周りの人がバージョンについて話しているのをよく聞きます。 当社を含め、ほとんどのソフトウェア会社がバージョン管理を真に実現するには、時間がかかると思いますが、プロジェクトチームが製品の納品を行うのではなく、市場を支援し、プロジェクトを迅速に納品するために、バージョンを管理することは困難であり、特に、さまざまな要件が満載で互換性のないプロジェクトでは、全員が疲弊してしまいます。この開発形態は、水平展開版と呼ぶべきだと思いますが、このようなプロジェクトはほとんどの企業が行っており、非常に大変でもあります。<version>Maven要做版本管理要有版本迭代机制要控制住版本！
この場合、初期段階で十分な調査が行われない場合、製品開発プロセスでは最初の顧客のニーズを直接ベンチマークし、その後の多数のプロジェクト実践に基づいて自社の製品を要約することがよくあります。所谓产品製品を要約した後、以前にデザインした4 つの単語を振り返ってください惨不忍睹。
理由は何ですか？開発の観点から見ると、確かにそうです项目要的急、需求不明确。
上記の問題を解決するにはどうすればよいでしょうか? 普通の企業では難しいと思います。私は以前にこの問題を検討したことがありますが、そのとき、いくつかの矛盾を理解しました。
- 製品による衝突。「製品は開発ではありません。開発者のほとんどは開発の作業方法を理解していません。彼らは理想主義者であり、多くの開発者には製品がありません。第一に、顧客の観点からアプリケーションを検討することが難しい場合があります。」したがって、お互いを考慮すると、私たち全員が共通の目標を持っているため、敵と同じである必要は実際にはありません。
- 社会的雰囲気からくる対立。
天下熙熙，皆为利来リーダーシップの観点から見ると、市場は非常に大きく、誰もが武道のことについて話さないことは誰もが知っています。より早く成功した人が、お金を稼ぎ、会社の経営をより良くする可能性が高くなります。会社の一員として、私たちはこのような環境の中で、企業の躍進を支援するのが私たちの仕事です。
これらの矛盾と現状は研究開発担当者が天秤にかけて決めるしかないので、水平的なバージョン管理は少ないほうが維持されるのではないかと個人的には思っています。
成長の過程には常に痛みが伴います。さあ、みんな！以下の内容は、「Maven 実戦」を研究し、私自身の理解を組み合わせてまとめたものです。
文章
1. バージョン管理
ここまでくだらないことを言ってきましたが、バージョン管理とは何でしょうか? まず第一に、健全なプロジェクトには通常、長期的かつ妥当なバージョン進化プロセスがあります。バージョン管理とは、プロジェクトのバージョン全体の1.0-SNAPSHOT------1.0------1.1-SNAPSHOT----進化などの進化プロセス管理を指します。これは、開発スナップショット バージョンから安定バージョンへのスナップショット開発バージョンの次のバージョンへのアップグレードを継続するプロセスを反映しています。(SNAPSHOT はスナップショット バージョンと呼ばれます)これは、バージョン管理ツールを使用してコードのすべての変更記録を追跡するSNAPSHOTとは異なる
ことに注意してください。版本控制版本管理版本控制
2. バージョン番号
2.1 バージョン番号の構成
他の依存関係を導入する場合、多くの場合1.2.1、1.7、1.0-SNAPSHOT、1.1-release、などの2.3-alphaバージョンが表示されます。ただし、その構成は比較的単純で、Maven バージョンの構成は次のようになります。
<主版本>.<次版本>.<增量版本> - <里程碑版本>
通常の状況下では主版本常に次版本存在し、比較的少数增量版本しか里程碑版本見られません。
メジャーバージョン: プロジェクトに対する主要なアーキテクチャ変更を示します。などstruts2、struts1異なるアーキテクチャを採用しています。
マイナーバージョン: 大規模な機能の追加や変更、バグ修正が行われ、アーキテクチャの変更は伴いません。
増分バージョン: 重大なバグの修正を示します。プロジェクトのリリース後に機能に影響するバグが発生し、時間内に修正された場合は、増分バージョンでの変更となります。
マイルストーンバージョン：特定のバージョンのマイルストーンを示すことが多く、よく見られます。また、、、、などもsnapshotあります。alphabeta1.0-SNAPSHOT3.0-alpha-11.1.2-beta-2
2.2 スナップショットの概要
通常、開発段階では、pom.xmlMaven プロジェクトで現在のプロジェクトのバージョン番号の後に が付いていることがわかりますがSNAPSHOT、これは何を意味するのでしょうか? どのようなシーンで使用されますか？
snapshotスナップショットのバージョンを示します。これは安定したバージョンではなく、開発プロセスで使用されるバージョンに属します。プロジェクトが継続的な反復開発期間にある場合、Aプロジェクトチームが開発後にリリースした新しいパッケージをBプロジェクトチームが参照するなどの依存関係がある場合、このときのスナップショットバージョンを取得することができます。 A プロジェクト チームがウェアハウスにリリースした後に使用されsnapshot、最新のタイムスタンプのサフィックスに変換され、B プロジェクト チームが自動的に参照できるようになります。
この利点は、依存関係を持つ 2 つのプロジェクト チームが同時に開発された場合、それらが互いに影響を与えないことです。プロジェクト チーム A がリリースされるたびに、プロジェクト チーム B は更新および再コンパイルされ、最新のプロジェクト プロジェクト A に自動的に更新されます。 . 開発の依存関係。テスト段階に入る準備ができた場合にのみ、マイルストーンのバージョン番号がまたは、つまりテスト バージョンにSNAPSHOT置き換えられます。alphabeta
2.3 ベータ版alpha、beta
プロジェクトを開発するとテスト版に入りますが、テスト版は大きく内部测试 alpha版2外部测试 beta版種類に分かれます。
alpha違いbetaは、betaバージョンは公開されるが、alphaバージョンは公開されないことです。
- アルファ (α): プレビュー バージョン、または内部ベータ バージョン。通常は外部にリリースされず、バグが多くなります。通常はテスターのみが使用します。
- ベータ (β): ベータ バージョン、またはパブリック ベータ バージョン。この段階のバージョンには常に新しい機能が追加されます。アルファ バージョンの後に開始されます。
テスト段階なので、変更が前後することは間違いありません。マイルストーンのバージョン番号はどのように並べ替えられていますか? それは、たとえば、字符串进行比较大小的>1.3-alpha-2に基づいています1.3-alpha-10。
以下に示すように、いくつかの拡張子があります。
拡張子 1 :
α、β、λ 常用来表示软件测试过程中的三个阶段。
-- α(alpha) 是第一阶段，一般只供内部测试使用；
-- β(beta)是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存
在缺陷和漏洞，一般只提供给特定的用户群来测试使用；
-- λ(lambda)是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的
优化处理即可上市发行。
拡張子 2 :
二.软件开发版本分类描述
Alpha：软件或系统的内部测试版本，会有很多Bug，仅内部人员使用
Beta：软件或系统的测试版本，这一版本通常是在Alpha版本后，会有很多新功能，
同时也有不少Bug
Gamma：软件或系统接近于成熟的版本，只需要做一些小的改进就能发行
RC（Release Candidate）：候选版本，这一版本不会增加新功能，多要进行Debug
GA（General Available）：正式发布版本，这个版本就是正式的版本
一个介绍的好文章地址： 软件的 Alpha、Beta、GM、RC、GA 等版本到底是啥意思
https://www.bilibili.com/read/cv9270313
2.4 rc、、、、、安定版final_ stable_releaseGA
テストに合格すると正式版に入ります 正式版は異なるものが多いですが、おそらくこれらは数種類でしょう。ほとんどの正式バージョンには何も表示されず、 などの単純なバージョン番号だけが表示され1.0ます1.7.1。rc、final、stable、releaseなどの個別のものもありますGA。
正式バージョンは安定バージョンであり、現在の期間で変更されることはありません。つまり、テストに合格し、バージョンを外部にリリースできることを意味します。
正式バージョンもソートされており、そのソートはマイルストーンのバージョン番号とは異なります (数字进行排序例: 1.10.1> 1.7.1> ) 1.5。
ここで皆さんに注意していただきたいのは、通常は依存関係をダウンロードし、不安定なバージョンはダウンロードしないようにしているということです。基本的に、そのようなバージョンには問題があります。安定したバージョンがある場合は、安定したバージョンを使用するようにしてください。
nacos2.5 オープンソースのバージョンの反復を確認する
バージョン番号を調べるときに、特に主要なメーカーのバージョンの反復を検索したので、nacosこれを見つけました。git アドレスからnacos ソース コード アドレス
にアクセスできない場合がありますが、tagそこから git バージョンを送信すると、何かを見つけることができます。
おそらく以下の順序で理解できるでしょう。（数字の変化に注目してください）
簡単に説明すると、開発期間中、最初はすべてのSNAPSHOTバージョンです。
開発が完了すると内部テストのalphaバージョン段階に入り、内部テストの段階でマイルストーンのバージョン番号がインクリメントされますが、インクリメントする際は文字列をもとにソートしてインクリメントされますが、一般的にはそれほど多くは出てきません。（ナコスを参照）。
内部テストが完了したら、betaパブリック ネットワークのテスト版の段階に入ります。もちろん、テストによっては 1 つの環境しか持たず、内部ネットワークとパブリック ネットワークに分割されません。ここでは、夢の環境であると仮定し、ははは。もちろん、マイルストーンのバージョン番号が増加するか、文字列に基づいて並べ替えが行われます。
パブリックネットワークのテストが安定すると、安定化予定のバージョンが起動しますが、RC基本的にはこのバージョンで問題なく、出る可能性がありますが、下図のようにあることが分かりnacosます
。RCバージョンに問題はなく、実際の最終安定版リリースが表示されます。マイルストーンのバージョン番号を削除して正式バージョンを作成します。
ボスが新しいアイデアを思いつき、アップグレードを開始すると、次のラウンドに進みますsnapshot。
3. 最後に
バージョン番号の方が重要だと思いますが、上記はあくまで「Maven Combat」を参考に私が理解した内容と個人的なまとめです。私があなたを誤解させないことを願っていますが、私が間違っている場合は、時間内に修正してください、ありがとう。
次の記事では、maven の強力なscopeタグについて詳しく説明します。