On Feb 10, 2009, at 11:44 AM, Akinori MUSHA wrote:

> At Tue, 10 Feb 2009 22:32:19 +0900,
> David A. Black wrote:
>> The problem is, though, that if a customer says, "We will only run
>> 1.8", it usually either means 1.8.6, or else it means "We don't trust
>> 1.9". I can't help thinking that the big thing is to get people to
>> trust 1.9, and to smooth out any remaining problems with 1.9. Right
>> now, it may be that the 1.8 "brand" has more trust, but that's just a
>> coincidence of the numbering. If 1.8.7 had been 1.9.0, and 1.9.1 were
>> 2.0, there would not be the same branding effect. (I know that's just
>> speculation, but I do think that 1.8.x is having to play an awfully
>> large number of roles.)
>
> Agreed.  Maybe it's time to (re)define the versioning scheme.  As I
> said in another mail, I always feel twisted when the second version
> number is called "minor".  What is more, even sharing the first two
> numbers did not always mean API compatible before 1.8.6.

I would hope that some consideration is given to how people expect  
version numbers to work. As you stated before, you've been thinking  
about ruby's versions like epoch.major.minor, but I'd expect that no  
one else has been.

This causes massive confusion and doubt about ruby. When a user  
upgrades to 1.8.7 and a significant amount of code begins to fail,  
they worry. When the upgrade to 1.8.8 and discover they've been using  
new syntax that their coworkers don't have, they get worried.

They get worried because when they see a change in the 3rd number,  
they don't expect "this release breaks backward compatibility in major  
ways."

We can do little to change their expectations of this fact sadly,  
because this is the way almost all open source software uses version  
numbers.

In my opinion, we're doing everyone a dis-service by calling YARV and  
the trunk 1.9. It's such a huge rewrite, it clearly should be at the  
very least 2.0. If we did that, people would
   1) Be quite happy there was a new ruby major release, as there as  
never been one.
   2) Be very aware that it changes a lot, and it's not a simple thing  
to upgrade

The problems with the current situation are compounded by the fact  
that trunk is currently called 1.9.1, which indicates it's a minor  
change from 1.9, which is completely false.

As 1.9 stabilized, it should have been upgraded to 2.0 and begun life  
as a normal, new major release.

We can not continue to consider using the first number if the version  
a forbidden thing. It is holding back ruby in the eyes of the  
programming community, and it's making us all fight amongst ourselves.


>
>
>> I admit I've always been skeptical of the gradual migration approach.
>> I don't see how it plays out with actual code, and I've never talked
>> to anyone who actually does it or wants to do it. I know a few people
>
> In my view, every new piece of code you write or add is part of
> migration, like avoiding upgrade-unsafe method, using a new method
> that performs well, etc. .
>
>> who have run 1.8.7 (I installed it to learn about it but don't use
>> it), but by far the majority of opinions I've heard amount to: use
>> 1.8.6, or make the move to 1.9.
>
> That's not a surprise for me considering that 1.8.6 was the first
> version that had decent continuous support by a decent maintainer
> under a decent policy.  I'm proud of that, and proud of Shyouhei.
>
> However, there are still bugs found in the 1.8 series and some of them
> are difficult to fix in 1.8.6 due to its strict backward compatibility
> policy or implementation defects.
>
> I would suggest frameworks and libraries move at least to 1.8.7 soon.
> Incompatible changes from 1.8.6 are minimal, and all user visible
> changes are documented.  If any of you have any problem in upgrading,
> please let me know.  Maybe I can give some clues.
>
> Adopting 1.9 now for production is a brave move, but frameworks and
> popular libraries should prepare for that as soon as possible.  While
> at fixing version dependent parts, make good use of backports in 1.8.7
> wherever appropriate to reduce code.

This is absolutely true, but by creating more confusing in the 1.8  
release process, everyone suffers. The company that is considering  
using ruby for the first time can easily say "They're not stable  
across releases."

The question should be asked, what is the point of 1.8.8? Is it to aid  
in migrating people to 1.9? If so, do not release it as 1.8, as it is  
not a maintance release for 1.8! As David Black mentioned, call it  
something like 1.8x9 or something.

Something that says "this is a release for people transitioning to 1.9"

If thats not said, people won't know why 1.8.8 is put out. They'll  
assume it's because there are bug fixes, when thats not at all why it  
was put out.

I pled with you to reconsider making drastic changes to 1.8. It will  
only create confusion, uncertainty, and doubt about ruby and the ruby  
community.

  - Evan Phoenix