uu59のメモ | semverによって演繹される世界とnpmのバージョン指定がちょっと変わる話
If at first you don't succeed; call it version 1.0. npmのバージョン指定が少し変わるらしい。 “npm install –save” No Longer Using Tildes npmのpackage.jsonでバージョンを固定するとき、~1.2.3と指定しておくと1.2.x(xは3以上でなるべく大きいもの)をインストールしようとします。これがデフォルトで^1.2.3のようになり、1.x.y(1.2.3以上で2.0.0未満のうち最新のやつ)をインストールしようとするようになったらしい。 semver、Semantic Versioningが定義するところでは、マイナーバージョンアップ(1.2.3→1.3.0)は後方互換性を壊さないはずなので^にしても理論的には問題なく、あったとすればそのパッケージのバージョニングが悪いという感じになり
ウェブデザインにおけるセマンティック・バージョニング
アプリケーションの世界ではセマンティック・バージョニングが広く受け入れられた……かどうかはわからないが、採用例はすごく増えている印象だ。ウェブデザインではどうかというと、ウェブ・アプリケーションのバージョニングに追随しているだけであったり、そもそもバージョニングされていなかったりするような気がする。ウェブデザイン、主にCSS(とCSSプリプロセッサー)においてセマンティック・バージョニングを導入するとすると、どのようなタイミングでメジャー、マイナーそしてパッチ番号を増やせば良いのだろうか。 セマンティック・バージョニングの中心となる概念は後方互換性だ。後方互換性が: 失われる: メジャー 失われない新機能の追加: マイナー 失われない修正: パッチ 数語でまとめるとこのようになるだろう。ウェブデザインにもこれを当てはめるとすると、ウェブデザインにおける後方互換性とは何なのかということをまず
Ruby 2.1.0 以降のセマンティックバージョニングについて
Posted by zzak on 21 Dec 2013 Translated by makimoto Ruby 2.1.0 以降、Semantic Versioning (日本語訳) に寄せたバージョニングに移行することを決定しました。 Ruby に、より明確で適切なバージョニングスキーマを提供するため、われわれは以下のポリシーに段階的に移行します。 ポリシーの変更 このポリシーは、 ruby-lang.org の管理者である柴田博志 (@hsbt) の提案にもとづくものです。 バージョンスキーマ MAJOR: MINOR リリースで対応できない互換性のない変更がある場合に増加する。 特別なイベントのために予約される。 MINOR: クリスマスごとに増加する。 API レベルでの非互換がありえる。 TEENY: API 互換性を維持するセキュリティフィックスやバグフィックス。 2.1.
Semantic Versioning 2.0.0
english セマンティック バージョニング 2.0.0 概要 バージョン番号 MAJOR.MINOR.PATCH を前提として、 あなたが互換性のない API の変更を行うときに MAJOR バージョンを、 後方互換性のある方法で機能性を追加したときに MINOR バージョンを、 そして、後方互換性のあるバグ フィックスをしたときに PATCH バージョンを、 インクリメントします。 追加のラベルとして、プレリリースとビルド メタデータが MAJOR.MINOR.PATCH フォーマットへの拡張として利用することができます。 序論 ソフトウェア マネジメントの世界には「依存関係地獄」と呼ばれる非常に恐ろしい場所が存在します。 あなたのシステムがより大きくなるほど、あなたのソフトウェアの中へより多くのパッケージを溶け込ませるほど、いつかこの絶望の底にいるあなた自身に気づく、そんな可能性が
SemVerのv1.0.0とv2.0.0-rc.1、node-semverを見比べてみた - L4L
npmモジュールのバージョニングについて調べてたらその標準仕様SemVerっていうのを発見したんだけど、よく読むとnpmモジュールのそれとは微妙に違うものになってるようなのでそこらへんまとめておく。 http://semver.org Semantic Versioningということで、バージョニングに意味を持たせようという話。公開されたAPIを持つライブラリなどが新しいバージョンをリリースする際、例えばそれが後方互換を保っているリリースなのか、機能追加もなくAPIがまったく変更しないバグFIXのようなリリースなのかをバージョン番号の上げ方で表現しようと。 このspecification自体もこのバージョニング仕様に則っており現在はv2.0.0-rc.1。その前バージョンv1.0.0は同サイトで公開されている。 SemVer v1.0.0 - http://semver.org/spec/
Bower入門(応用編) - from scratch
Bower入門(応用編) さて、応用編を書いていきます。 基礎編ではBowerのインストールとライブラリ管理する上での基本的なコマンドを紹介しました。 応用編ではBowerのライブラリを管理する上で利用するべきツールやライブラリを公開する上で心がけるべきことについて書いていきます。 少し長いのでサマリ Bowerを管理する上で利用すると良いツール：grunt-bower-taskがオススメです ライブラリを公開する上で心がけること、その1：mainとignoreをちゃんと書きましょう ライブラリを公開する上で心がけること、その2：ちゃんとgit tagを使ってバージョン管理しましょう Bowerからインストールしたライブラリを利用する場合 前回の基礎編で少し書きましたが、おさらいすると、Bowerはあくまでパッケージマネージャなので、インストールしてもフォルダ構造までは変えてくれません。
凡人プログラマーの独り言 Semantic Versioning 2.0.0-rc.1の和訳【日本語化】
Semantic Versioning 2.0.0-rc.1 はソフトウェアのバージョン番号の付け方について提案しています。 まだ和訳している人がいないようなので勝手に日本語版を作ってみました。 ただ、私は英語がすごく苦手な人なので誤訳が多いと思います。 正直自分でもどうかと思う部分も多々あるので、間違っている部分やもっと上手な翻訳を指南してもらえると幸いです。 翻訳について筆者であるTom Preston-Wernerに特別に連絡はしていません。 これはCreative Commonsライセンスの表示があったためです。 以下、和訳です。 Semantic Versioning 2.0.0-rc.1 日本語版 ソフトウェアマネジメントには、「依存関係の地獄」と呼ばれる恐ろしい場所が存在している。あなたがシステムを育て多くのパッケージを統合すると、ある日あなた自身がこの地獄の中にいることに気
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
