From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.1 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 3DF4D20248 for ; Mon, 25 Feb 2019 20:26:07 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C047E12107E; Tue, 26 Feb 2019 05:26:01 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 2ED84120F80 for ; Tue, 26 Feb 2019 05:25:58 +0900 (JST) Received: by filter0031p3las1.sendgrid.net with SMTP id filter0031p3las1-19526-5C744F56-C 2019-02-25 20:25:58.189149509 +0000 UTC m=+137581.933189494 Received: from herokuapp.com (ec2-54-166-78-40.compute-1.amazonaws.com [54.166.78.40]) by ismtpd0058p1mdw1.sendgrid.net (SG) with ESMTP id eV6LnvtTSFGKzoSm24NvSQ for ; Mon, 25 Feb 2019 20:25:58.073 +0000 (UTC) Date: Mon, 25 Feb 2019 20:25:58 +0000 (UTC) From: skalee@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 67071 X-Redmine-Project: common-ruby X-Redmine-Issue-Id: 15619 X-Redmine-Issue-Author: skalee X-Redmine-Sender: skalee X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS6Lo413MsxdtZuU6JNsBqfoJCb4NX6vTsM1tg Lb7gF3srT59VZuYxx/6r8jK0B+Y30BjXb5/dD31Pz/RzfrQ3+FukNb0ZjjFD86YUoQvO8vylf8WoC2 GVDLCSGnjrYy2V7XKA+S68XkEPYWlQFlNqk7 X-ML-Name: ruby-core X-Mail-Count: 91621 Subject: [ruby-core:91621] [CommonRuby Feature#15619] Support blacklisting certain dependency versions X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15619 has been updated by skalee (Sebastian Skalacki). Thanks for your suggestion. Moved to https://github.com/rubygems/rubygems/issues/2659. ---------------------------------------- Feature #15619: Support blacklisting certain dependency versions https://bugs.ruby-lang.org/issues/15619#change-76884 * Author: skalee (Sebastian Skalacki) * Status: Third Party's Issue * Priority: Normal * Assignee: * Target version: ---------------------------------------- # Abstract This feature request proposes introducing a new dependency constraint "!=", which will allow to blacklist a specific buggy version of some gem dependency without dropping support for older releases. # Background I am developing a gem which extends functionality of the Mail gem. It works with Mail 2.6.4 onwards (the current latest is 2.7.1), therefore I'd normally define a dependency constraint as combination of "~> 2.6" AND ">= 2.6.4". However, there is one exception: Mail version 2.7.0 has some bug, which is fatal for my gem. This bug has been fixed in 2.7.1. I need to prevent users from using the buggy version of Mail with my gem. Currently, I can do following: 1. Bump version constraint on Mail gem to "~> 2.7" AND ">= 2.7.1". 2. Release two separate gems (or versions), one with constraint "~> 2.6.4", and another with "~> 2.7" AND ">= 2.7.1". 3. Display a proper message in README and post-install step in order to inform users that they should care about Mail version themselves (e.g. constrain it in their gemfiles). 4. Perform a runtime check, and raise exception on incompatible Mail version. 5. Any reasonable combination of above. Option 1 seems to be the best. It is easy and very straightforward, also it does not break Bundler's gem resolution. However, it seems wrong to remove support for older versions only because single version of Mail is buggy. What is more, such change to dependencies may be considered as a breaking one. Option 2 adds an unnecessary maintenance burden, and feels odd in general. Options 3 and 4 are also quite odd, as they seem to be an unnecessary complication, and may surprise users who have just upgraded my gem. Actually, what I would really want to achieve is to be able to define dependency constraint as "~> 2.6" AND ">= 2.6.4" BUT NOT "= 2.7.0". # Proposal For this reason, I propose introducing "!=" version constraints which exclude unwanted version explicitly. For example, in my case I could write "~> 2.6" AND ">= 2.6.4" AND "!= 2.7.0". -- https://bugs.ruby-lang.org/