ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: skalee@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:91615] [CommonRuby Feature#15619] Blacklist certain dependency versions
Date: Sun, 24 Feb 2019 18:41:03 +0000 (UTC)	[thread overview]
Message-ID: <redmine.issue-15619.20190224184101.b09b4185ed5f1221@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15619.20190224184101@ruby-lang.org

Issue #15619 has been reported by skalee (Sebastian Skalacki).

----------------------------------------
Feature #15619: Blacklist certain dependency versions
https://bugs.ruby-lang.org/issues/15619

* Author: skalee (Sebastian Skalacki)
* Status: Open
* 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/

       reply	other threads:[~2019-02-24 18:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15619.20190224184101@ruby-lang.org>
2019-02-24 18:41 ` skalee [this message]
2019-02-24 19:42   ` [ruby-core:91617] Re: [CommonRuby Feature#15619] Blacklist certain dependency versions Rafael Mendonça França
2019-02-25  2:19 ` [ruby-core:91618] [CommonRuby Feature#15619] Support blacklisting " duerst
2019-02-25 20:25 ` [ruby-core:91621] " skalee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.issue-15619.20190224184101.b09b4185ed5f1221@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).