Semantic Versioning 2.0.0
english セマンティック バージョニング 2.0.0 概要 バージョン番号 MAJOR.MINOR.PATCH を前提として、 あなたが互換性のない API の変更を行うときに MAJOR バージョンを、 後方互換性のある方法で機能性を追加したときに MINOR バージョンを、 そして、後方互換性のあるバグ フィックスをしたときに PATCH バージョンを、 インクリメントします。 追加のラベルとして、プレリリースとビルド メタデータが MAJOR.MINOR.PATCH フォーマットへの拡張として利用することができます。 序論 ソフトウェア マネジメントの世界には「依存関係地獄」と呼ばれる非常に恐ろしい場所が存在します。 あなたのシステムがより大きくなるほど、あなたのソフトウェアの中へより多くのパッケージを溶け込ませるほど、いつかこの絶望の底にいるあなた自身に気づく、そんな可能性が
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
本番環境でのperl/ruby/nodeのセットアップ - たごもりすメモ
本番環境にperlとかrubyとかnodeを入れるんだけど、もちろん system perl じゃやってられないので指定したバージョンのものを一般ユーザの管理下に突っ込みたい。 で、そういうのをこれまで perlbrew とか rvm とか rbenv とか nvm とか nodebrew とかでやってたんだけど、さすがに色々疑問が湧いてきた。バッチで単発実行するために eval "$(rbenv init -)" とかさすがにおかしくね？ みたいな。 ということで tokuhirom method 的にインストール用の簡単コマンドを使って実行、あとはパスを通せばいいじゃん、ということにしようかと思う。 参考: サーバーのセットアップは perlbrew とかじゃなくてよくね? という時のライフハック - blog.64p.org これ、今朝までは Perl::Build をどうにかしてC
モジュールのバージョンを確認するときどうやってますか？ - Articles Advent Calendar 2010 Casual
もう恋なんてしないなんて、言わないよ絶対kamipoです。 ときに皆さん、Perlのモジュールのバージョンを確認するときどうしてますか？ 僕はPerlをはじめた最初のころ、ずっとこうやっていました。 $ perl -MAcme::Hidek -le 'print $Acme::Hidek::VERSION' 40.0 こうやってたの、僕だけじゃないですよね！？ いまでは以下のワンライナーにaliasを張っているので毎回がんばってワンライナーを打たなくてよくなりました。 $ alias pmversion='perl -le '"'"'for $module (@ARGV) { eval "use $module"; print "$module ", ${"$module\::VERSION"} || "not found" }'"'" $ pmversion Acme::Hidek Ac
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
Subversion によるバージョン管理
このような FAQ の問題点は、文字通り FAQ でも何でもないというところ です。技術サポートに電話をして「どうやったら生産性が最大になる のでしょうか?」などと聞く人は一人もいないのです。そうではなく、 本当はもっとずっと具体的な質問がしたいのです、たとえば「どうやったら カレンダーシステムを変更して一日前でなく、二日前に通知するように できますか?」のような。しかし本当の問題点を明らかにするより、 仮想的な FAQ を作るほうがずっとやさしいのです。本当の FAQ を作るには 忍耐強い、組織的な努力が必要なのです: ソフトウェアの一生を通じて やってくる問いを追いかけ、それに対する答えを見守り、それらすべてを 集めて経験の浅いユーザの集約的な経験を反映するように検索可能な形に まとめる必要があります。それは忍耐が必要で、自然主義者のように物事 を黙って観察する態度が必要になります。こ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
)
http://developer.pankia.com/wiki/index.php/%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E9%80%9A%E7%9F%A5(iOS)