タグ付けされた質問 「semantic-versioning」

1
APIを使用しないプログラムにセマンティックバージョニングを適用する方法
でhttp://semver.org/ -which私の認識では、ブレークは/ APIを変更し、その変更が導入されたときにメジャーバージョン番号を増やすことをお勧めしますversioning-で最も広く使用されている慣例のようです。 ただし、このガイドラインの適用方法がわからない2つの関連シナリオがあります。 コードがAPIを提供しない場合はどうなりますか?コードをバージョン管理するにはどうすればよいですか? コードの開発後期にAPIの提供を開始したらどうなりますか?

2
build.numberがセマンティックバージョニングの「乱用」なのはなぜですか?
提案されたビルドシステム(Gradle / Artifactory / Jenkins / Chef)をシニアアーキテクトの1人に説明していましたが、彼は私に同意しませんでしたが、実際に計量するのに十分な経験はありませんでした。 このプロジェクトは、他のチームが再利用するアーティファクトとしてJavaライブラリ(JAR)を構築します。バージョン管理には、次のセマンティックアプローチを使用します。 <major>.<minor>.<patch> どこにpatchバグ/緊急フィックスを示し、minor下位互換性リリースを示しており、majorいずれかのAPIの大規模なリファクタリングおよび/または互換性のない変更を示します。 ここでの配信に関しては、私が望むものです。開発者がコードをコミットします。これにより、QA / TEST環境へのビルドがトリガーされます。一部のテストは実行されます(一部は自動化され、一部は手動)。すべてのテストに合格すると、プロダクションビルドがJARを社内リポジトリに公開します。この時点までに、JARは適切にバージョン管理される必要があり、build.numberCIツールによって自動的に生成および提供されるものを使用して、パッチ番号として機能させることを考えていました。 したがって、バージョン管理は実際には次のようになります。 <major>.<minor>.<build.number> ここでも、build.numberCIツールによって提供される場所。 アーキテクトはこれを却下し、CIビルド番号の使用はセマンティックバージョニングの「乱用」であると述べました。 私の質問は次のとおりです。これは正しいですか?もしそうでなければ、なぜですか?

4
コミットにバージョンタグを付けないのはいつですか?
コンテキスト:最近、セマンティックバージョニングについて知り、自分のプロジェクトで実際にそれを最適に使用する方法を決定しようとしています。 semverがバージョニングのために大きな変更、小さな変更、およびパッチを考慮に入れていることを考えると、いつコミットに更新されたバージョンのタグを付けるべきではないでしょうか?すべての変更がこれらのカテゴリのいずれかに収まるように思えるので、すべての変更をバージョン管理する必要がありますが、GitHubで人気のあるさまざまなプロジェクトを見ると、これは物事が行われる方法ではないようです(大規模なプロジェクトには数万件のコミットがあり、タグは数百件しかありません)。

5
バージョン番号はいつ増やすべきですか?
私は学校でプログラミングを学ばなかったし、(プロの)開発者として働いていないので、基本的なことの多くははっきりしていません。この質問では、そのうちの1つを明確にしようとします。 今度は、私は問題を抱えていると仮定しましょう#1、#2そして#3バージョンの強化/修正されるように設定されている私の問題トラッカーで1.0.0、最後の(安定)バージョンであること0.9.0。 いつバージョンを増やすべき1.0.0ですか?a)上記の問題の1つのみがクローズされた場合、またはb)バージョンに関連するすべての問題1.0がクローズされた場合 それを行う正しい方法はどれですか?そして、正しい方法で、私は業界で現在使用されているものを意味します。

2
重要なバグを修正する際のセマンティックバージョニング
私は現在、多くのパブリックな用途があるライブラリを管理しており、セマンティックバージョン管理について質問がありました。正しく実装されていないライブラリのかなり重要な部分をリファクタリングしたい-そして常に正しく実装されていない。ただし、これを行うと、パブリックAPIが変更されることになり、これは大きな決断です。 私が行いたい変更は、イテレータの使用方法を中心に展開します。現在、ユーザーはこれを行う必要があります。 while ($element = $iterator->next()) { // ... } 少なくともPHPのネイティブIteratorインターフェイスでは、これは正しくありません。これに置き換えたい: while ($iterator->valid()) { $element = $iterator->current(); // ... $iterator->next(); } これは次のようなものです: foreach ($iterator as $element) { // ... } トムのセマンティックバージョニングのガイドを見ると、パブリックAPIへの変更(つまり、下位互換性のないもの)はメジャーリリースを正当化すべきであると明確に述べています。したがって、ライブラリは1.7.3から2.0.0にジャンプしますが、これは私にとってはあまりにも大きな一歩です。修正される機能は1つだけです。 最終的に2.0.0をリリースする計画はありますが、ライブラリを完全に書き直し、多数のパブリックAPIの変更を実装したときだと思いました。このリファクタリングの導入は、メジャーバージョンリリースを保証しますか?私は本当にそれがどのように見えるかわかりません-私は1.8.0または1.7.4としてそれをリリースすることをより快適に感じます。誰かアドバイスがありますか?

4
高速なメジャーバージョンバンピングは、デザインの悪さの証拠ですか?
私は数ヶ月前にジュニアプログラマーとして仕事を始めました。私たちが取り組んでいるシステムは、2年ほど実稼働しています。私はシステムと設計の物inいには関与していませんでした。 私が気づいたことの1つは、システムのメジャーバージョンがすでに11.YZであるということです。他のシステムやライブラリでの作業経験から、製品がメジャーバージョンをそれほど速く動かしたのを見たことはありません。1.XYで長年使用されている製品がありますが、まだ機能とバグ修正を受けています。 セマンティックバージョニングが適切に使用されていると仮定すると、これは、システムがほぼ4か月ごとに重大な重大な変更を行うため、設計が不十分であることを示していますか?

2
セマンティックバージョニングでは、バージョン番号に4つのコンポーネントを使用できますか?
私が見たセマンティックバージョニングのすべての例は、使用中の3つのコンポーネントを示しています。ピリオド文字は2つまでです。では$DAYJOB、リリース番号で4つのコンポーネントを使用しています。 5.0.1.2 セマンティックバージョニングはこれを許可しますか? そして、より高レベルでより議論の余地のある副質問として、それは本当に重要なのでしょうか?セマンティックバージョニングを実施するのは良い考えだと思い始めましたが、最終的にはPCIなどのエンティティがそれをオーバーライドします。 PCIコメントについて明確にすべきでした。問題は、主要コンポーネントとマイナーコンポーネントが変更されたときに監査とそのコストが影響することであり、必ずしも真の新機能ではありません。たとえば、支払いに関連する機能が導入された場合、PCIのマイナー番号を増やします。ただし、GUIの何かに関連するまったく新しい機能を追加しても、追加されません。パッチのみが変更されます。したがって、この場合、他の誰かがそれらの決定を下すため、開発者としての問題について実際には発言権を取得しません。

5
ユーザーが機能だと思ったバグをどのように処理しますか?
質問: エンドユーザーが機能だと思ったバグに対処する適切な方法は何ですか? 精緻化: かなりの割合のユーザーが機能として期待している場合、より安定させるために「未修正」または「修正済み」のままにしておくべきだと思いますか?ただし、ユーザーのごく一部が0.1%または1%などの機能であると期待している場合は、このバグを修正する必要があります。 理論的には、これはマイナーなバグ修正であるため、セマンティックバージョニングで考慮されるようにPATCHとして認定できます:xyZ それが文書化されている限り、(機能として意図されていないので)PATCHとしてまだ資格がありますか? 編集:この特定のケースでは、他の開発者が使用する内部使用ライブラリのAPIのバグです。

3
Git、セマンティックバージョニング、およびそれが(私の)典型的な開発タイムラインにどのように適合するか?
Q&Aシステムに取り組んでいて、現在のアプリケーションに最初の公式バージョン/タグとして「1.0.0」のタグを付けようとしています。ベータテストのために、次に限定されたテスト対象者にロールアウトするところです。この段階で「1.0.0」は正しいですか? また、その段階で多くのバグが見つかることは間違いありません。「1.0.0」のままにしておきますが、リリースされるまでタグを強制的に移動します。または、バグを修正したら、新しいタグ「1.0.1」を付けますか。その後、おそらく「1.0.2」のテストを繰り返します。 したがって、拡張機能(たとえば、新しいメニュー、新しい検索入力フィールドなどの新機能)に取り組む場合、これらは「1.0.0」から「1.1.0」へのように小さな変更でしょうか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.