[ruby-core:91615] [CommonRuby Feature#15619] Blacklist certain dependency versions

[ruby-core:91615] [CommonRuby Feature#15619] Blacklist certain dependency versions

[skalee]

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/

[ruby-core:91617] Re: [CommonRuby Feature#15619] Blacklist certain dependency versions

[Rafael Mendonça França]

[-- Attachment #1.1: Type: text/plain, Size: 2968 bytes --]

This constraint already exists and work.  You can define `gem.add_dependency
'mail', '~> 2.6', '>= 2.6.4', '!= 2.7.0'`.

See
https://github.com/rubygems/rubygems/blob/89ce39a27611f7a791562cecf53bf2d773ae105f/lib/rubygems/requirement.rb#L7

On Sun, Feb 24, 2019 at 13:41 <skalee@gmail.com> wrote:

> 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/
>
> Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
>

[-- Attachment #1.2: Type: text/html, Size: 4842 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

[ruby-core:91618] [CommonRuby Feature#15619] Support blacklisting certain dependency versions

[duerst]

Issue #15619 has been updated by duerst (Martin Dürst).

Status changed from Open to Third Party's Issue

This request makes a lot of sense to me.

However, while the gem library is part of Ruby, they are developed separately. I suggest you submit your request to https://github.com/rubygems/rubygems/issues.

----------------------------------------
Feature #15619: Support blacklisting certain dependency versions
https://bugs.ruby-lang.org/issues/15619#change-76882

* 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/

[ruby-core:91621] [CommonRuby Feature#15619] Support blacklisting certain dependency versions

[skalee]

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/