Re: Ruby 2.3.2

2016-12-01 Thread Vít Ondruch
Dne 28.11.2016 v 12:39 Mamoru TASAKA napsal(a): > Vít Ondruch wrote on 11/28/2016 07:41 PM: >> Actually, since there were some people hitting this issue on devel ML, >> shouldn't we revert this patch for stable Fedoras? I.e. 23-25 and keep >> it for Rawhide only? There are two days left until the

Re: Ruby 2.3.2

2016-11-28 Thread Mamoru TASAKA
Vít Ondruch wrote on 11/28/2016 07:41 PM: Actually, since there were some people hitting this issue on devel ML, shouldn't we revert this patch for stable Fedoras? I.e. 23-25 and keep it for Rawhide only? There are two days left until the updates become stable ... Honestly speaking, although ru

Re: Ruby 2.3.2

2016-11-28 Thread Vít Ondruch
Actually, since there were some people hitting this issue on devel ML, shouldn't we revert this patch for stable Fedoras? I.e. 23-25 and keep it for Rawhide only? There are two days left until the updates become stable ... Vít Dne 22.11.2016 v 12:46 Vít Ondruch napsal(a): > > Dne 21.11.2016 v 1

Re: Ruby 2.3.2

2016-11-23 Thread Vít Ondruch
Dne 23.11.2016 v 03:53 Joe Rafaniello napsal(a): > > > On Tue, Nov 22, 2016 at 6:57 AM, Vít Ondruch > wrote: > > Not mentioning that this wording was introduced quite recently [1] and > from the commit, there is no obvious that it would be meant as "the >

Re: Ruby 2.3.2

2016-11-22 Thread Joe Rafaniello
On Tue, Nov 22, 2016 at 6:57 AM, Vít Ondruch wrote: > > > Dne 21.11.2016 v 16:48 Chris Arcand napsal(a): > > This doesn't break semver. > > > > It does not introduce a backwards incompatible change from the Ruby > ecosystem's perspective (the change is within internal specifications and > is comp

Re: Ruby 2.3.2

2016-11-22 Thread Vít Ondruch
Dne 21.11.2016 v 16:48 Chris Arcand napsal(a): > This doesn't break semver. > > It does not introduce a backwards incompatible change from the Ruby > ecosystem's perspective (the change is within internal specifications and is > completely compatible with previous versions of Ruby/RubyGems). Y

Re: Ruby 2.3.2

2016-11-22 Thread Vít Ondruch
Dne 21.11.2016 v 17:33 Jason Frey napsal(a): > Here's the Pull Request and commit that introduced the change. > > https://github.com/rubygems/rubygems/pull/1371 > > The Pull Request shows that the purpose of the change is to fix a memory > allocation issue. On large projects with a number of Ru

Re: Ruby 2.3.2

2016-11-21 Thread Jason Frey
Here's the Pull Request and commit that introduced the change. https://github.com/rubygems/rubygems/pull/1371 The Pull Request shows that the purpose of the change is to fix a memory allocation issue. On large projects with a number of Rubygems it can reduce String allocations by nearly 50%.

Re: Ruby 2.3.2

2016-11-21 Thread Chris Arcand
This doesn't break semver. It does not introduce a backwards incompatible change from the Ruby ecosystem's perspective (the change is within internal specifications and is completely compatible with previous versions of Ruby/RubyGems). You're expecting a semver contract with internal gem speci

Re: Ruby 2.3.2

2016-11-19 Thread Vít Ondruch
Hi Joe, This is what semver [1] says about changes in "patch" version: > PATCH version when you make backwards-compatible bug fixes. It specifically speaks about "bug fixes". I can't see any bug which freezing all strings in generated .gemspec solves. Such change should never be part of the p

Re: Ruby 2.3.2

2016-11-18 Thread Joe Rafaniello
Hi Vit, I'm not sure how this is something that upstream ruby/rubygems can know. How is this a breaking change? It's completely compatible with older versions of ruby. We're tying our .spec file to very specific details of a .gemspec and hacking it with sed. Anytime we modify upstream source code

Re: Ruby 2.3.2

2016-11-18 Thread Vít Ondruch
Forgot to mention that this will influence f24 -> Rawhide ... not sure about f23 yet ... Vít Dne 18.11.2016 v 21:38 Vít Ondruch napsal(a): > Hi, > > I am slowly pushing Ruby 2.3.2 into Fedora. > > Unfortunately, part of Ruby 2.3.2 is update of RubyGems and this update > has one annoying conse