問題タブ [semantic-versioning]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
9228 参照

maven - Mavenバージョンのsemver Major部分を取得するには?

<Major>.<Minor>.<Patch>のメジャー バージョン ( )を入手できproject.versionますか?

たとえば、私のバージョンがの場合、後で同じ pom.xml の構成で使用できる1.3.4ようにしたい1

何かのようなもの:

そうでない場合、代替手段は何ですか?

0 投票する
8 に答える
10415 参照

ruby-on-rails - Railsアプリケーションのバージョン番号はどこに保存しますか?

Railsアプリをバージョニングするときは、すばらしいセマンティックバージョニングパラダイムを使用します。私が持っていた1つの質問は、この番号をどこに保存するのが最適かということでした。/libenvironment.rbなどに保存されているのを見てきました。

人々がベストプラクティスについてどう思ったか疑問に思っていますか?

0 投票する
1 に答える
2647 参照

nuget - プレリリースのNuGetパッケージをVSPackageManager UIに表示できますか?

独自のNuGetパッケージを展開するためにカスタムNuGetフィードを使用しています。私はsemverを使用しているので、CIサーバーはビルドごとに新しいプレリリースパッケージをデプロイして生成しています。これらのプレリリースパッケージは、パッケージマネージャーのデフォルトでは明らかに表示されません。

パッケージ/フィード/グローバルレベルで、プレリリースパッケージをパッケージマネージャーの[更新]タブに表示するように指定する方法はありますか?

たとえばpackages.configファイルを編集してプレリリースパッケージをインストールすると、パッケージマネージャーでパッケージが赤い「プレリリース」ラベルで明確にマークされるため、マネージャーはバージョン管理を正しく理解します。

0 投票する
4 に答える
3748 参照

semantic-versioning - セマンティックバージョニングで「パブリックAPI」とはどういう意味ですか?

http://semver.org/から「セマンティック バージョニング」と呼ばれるルールを使用して、バージョン番号を割り当ててインクリメントする方法について学習しています。

すべての規則の中で、最初の規則は次のように述べています。

セマンティック バージョニングを使用するソフトウェアは、パブリック API を宣言する必要があります。この API は、コード自体で宣言することも、ドキュメントに厳密に存在することもできます。それがどのように行われたとしても、それは正確かつ包括的であるべきです」

「パブリック API」について混乱しています。それは何を指していますか?

0 投票する
4 に答える
310 参照

.net - ポータブルクラスライブラリへの移行は大きな変化ですか?

現在、各ランタイムを対象とする個別のバイナリを構築しています

  • .net 4
  • ウインドウズの電話
  • Silverlight

ライブラリを単一のポータブルクラスライブラリに移動し、機能を変更しない場合、これは重大な変更と見なされますか?

または、SemVerの用語では、メジャー、マイナー、またはパッチバージョンの変更ですか?

0 投票する
1 に答える
105 参照

open-source - ソフトウェアの再構築時にバージョン番号が変更される

以前はプロプライエタリであった Java ソフトウェア システムをオープンソース化しています。Tom Preston-Werner によるセマンティック バージョニングに大まかに従いました。

  • バグ修正は、パッチの更新を意味します (たとえば、1.0.X)
  • 下位互換性のあるパブリック API への変更は、マイナー アップデート (1.X.0 など) を意味します。
  • 下位互換性のないパブリック API への変更は、メジャー アップデート (X.0.0 など) を意味します。

システムをオープンソース化するために、パッケージの名前を変更する必要がありました。また、以前存在していたモジュールの多くを統合する必要があると感じました。

再構築タスクはパブリック API を変更しませんが、API ユーザーの依存関係を変更します。

再構築/パッケージの名前変更は、セマンティック バージョニングのどこに当てはまりますか? このような再構築は、よく知られているオープン ソース プロジェクトではどのように処理されますか?

0 投票する
4 に答える
4065 参照

continuous-integration - TeamCityを使用してセマンティックバージョニングを組み込むためのベストプラクティスは何ですか

TeamCityは優れたCIツールであり、セマンティックバージョニングを使用してDLLバージョンを長期間管理しています。現在、TeamCityとセマンティックバージョニングを統合するというアイデアに到達しています。その間、このトピックについて調査を行っています。お気に入り

MajorVersion.MinorVersion.PatchVersion.BuildNumber

常にteamcitybuildnumberを使用するbuildNumber、およびassemblyinfo.cs内で維持する他の3つのバージョンここでの質問は、teamcityを使用してビルド番号をassemblyinfo.csにフィードする方法です。Msbuildがこのパラメーターをサポートしていることがわかります。同じことを処理するためのベストプラクティス?また、開発者に公開されたバージョン情報として、バージョン全体をnugetパックにフィードしたいと思います。

どうもありがとう

0 投票する
0 に答える
2052 参照

ruby - Githubでプロジェクトのバージョン番号をバンプするタイミング

これは哲学の質問ですが、どうすればよいのでしょうか。

では、具体的な例を見てみましょう。私はGithubにプロジェクトを持っています、それはRubyの宝石です。

通常、新しいバージョンをリリースするときは、すべての機能と修正を完了してから、"Bumping version to v1.2.0"メッセージとしてコミットを作成し、変更ログの更新とVERSION継続的な更新のみを含めます。タグはこのv1.2.0コミットを指します。

しかしその後...

  • リポジトリに含まれるように、バージョンを直接再度バンプする必要がv1.3.0-alphaありますか?
  • プロセスのどこかで大きな変更を加えた場合、バージョンをに再バンプする必要がありv2.0.0ますか?
  • v1.2.xパッチリリースで動作するブランチを作成する必要がありますか?

あなたのプロセスと、このすべての周りで使用するための良い習慣は何ですか?追加のアドバイスはありますか?

皆さんありがとう !:)

0 投票する
1 に答える
12808 参照

nuget - How to create a nuspec dependency which includes prereleases

Some context:

I have 4 nuget packages with dependencies. They are all in pre-release mode, and they evolve from alpha to "stable" at their own pace. I want to be able to specify in the dependency definition that prereleases should be included, but when the "stable" version is available, it should update to the stable version.

In the NuGet Docs the rules for versioning are defining [ and ] to include the version number you specify and ( and ) to exlude the version number you specify.

Some examples on the impact of the versions in the nuspec file:

==> This will install MyComponent 1.2.0 or higher. (not including prerelease 1.2.0-alpha)

==> This will install MyComponent 1.2.0 or higher. (not including prerelease 1.2.0-alpha)

==> This will install MyComponent 1.2.0 until but not including version 2.0.0. (not including prerelease 1.2.0-alpha but includes prerelease 2.0.0-alpha)

Currently I set:

But I find this a very ugly way and it does not really reflect the reality. (What if version 1.1.32767.1 exists?)

I would like to know how to specify that you wish to include prerelease versions in the minimum version?

0 投票する
1 に答える
146 参照

ruby - セマンティック バージョニングのための ruby​​ gem パブリック API の記述

Semantic Versioning Specificationの最初のポイントでは、互換性のあるソフトウェアはパブリック API を宣言する必要があると述べています。

gem がこのパブリック API をどのように確立するのか疑問に思っています。これは通常、readme (たとえば、 ActiveRecordを参照) を介して行われるようですが、パブリック API コードと残りのコードの間に厳密な境界を引いているようには感じられません。これをより適切に行う宝石の例はTwitter APIで、その公開 API コードをAPI ディレクトリに配置しますが、公開 API の configure メソッドはAPI ディレクトリの外のtwitter.rbで定義されているため、その行は灰色です。

セマンティック バージョニング (バンドラーのようなツールがあることを考えると、ほとんどの場合) に固執しようとする gem の潜在的な貢献者として、公開 API の一部であるメソッドとそうでないメソッドを知りたいと思います。もっとソースコードを調べる必要があるかもしれませんが、パブリック API を明確に定義するためのガイドラインはどこかにありますか?