The front page of ruby-lang.org lists 1.7.2 as the current development
version, so that’s what I labelled the installer.
Okay - so assuming things need to be tightened up on the 1.7.2-1 installer,
and -2 comes out, it’ll just have the latest cvs snapshot at that time.
Gotcha.
Exactly. People are testing out 1.7.2-1 as we speak, so as soon as I get
a pile of bugs to fix (assuming they are things I can fix, i.e., bugs
in the installer not in the components), I’ll release a -2 with the
latest snapshot at that time.
/\ndy
Is this really a good idea ?
Is every snapshot of 1.7.2 equally stable ?
Since 1.7.2 seem to be a moving target, isn’t there an obvious risk
that each new snapshot can introduce new bugs (besides any new features).
I realize that this maybe isn’t something that you can solve,
but rather an issue with the way Ruby is developed.
People are “forced” to use 1.7.2 (because of various problems with
the 1.6.x line). Often the answer on this list when people ask about
a particular problem is: use 1.7.2 (or even the latest from CVS).
This causes problems if Ruby is to be used in a production
environment. I’m considering using Ruby more in such a setting, but
before I dare to do that I would like to see the following come
true:
- a "good" Windows version of Ruby.
I hope Andy's installer will become that version.
- it should be based on a "well-defined" version of Ruby.
If the 1.7 line is becoming the de-facto version people
are using, I think the handling of releases should be be more
"formal", so Andy can base his installer on a "real" release.
- if 1.7.2 remains as "floating" as it is today, the next best
thing would be if Andy told *exactly* what 1.7.2 snapshot he
uses for building his Windows Installer.
I need to use Ruby on several platforms (Windows, Solaris, Linux,…)
and I want to be able to use the same version on all platforms.
But I also want to use Andy’s Windows Installer, and today this is
an impossible equation …
I hope someone with knowledge of the way releases of Ruby
are made, can shed some light on the issues mentioned above.
/Johan Holmberg
···
On Wed, 14 Aug 2002, Andrew Hunt wrote:
[ Cris Morris wrote: ]
Okay - so assuming things need to be tightened up on the
1.7.2-1 installer, and -2 comes out, it’ll just have the latest
cvs snapshot at that time.
Gotcha.
Exactly. People are testing out 1.7.2-1 as we speak, so as soon as I get
a pile of bugs to fix (assuming they are things I can fix, i.e., bugs
in the installer not in the components), I’ll release a -2 with the
latest snapshot at that time.
/\ndy
Johan Holmberg holmberg@iar.se writes:
If the 1.7 line is becoming the de-facto version people
are using, I think the handling of releases should be be more
"formal", so Andy can base his installer on a "real" release.
This is the problem, rather than the solution.
We should not be seeing known problems being fixed only in the
development branch. If as a community we are serious about seeing Ruby
in widespread use, then we need to put priority into supporting the
stable releases: there should be no known problems in a 1.6 branch
that have solutions in a development branch. Instead, it should be the
norm that developers cannot introduce a solution into the development
tree before they have first solved the problem in the stable branch.
This is a serious issue. In my current project, I’m using 1.6.7. I
feel this is prudent. However, 1.6.7 has two showstopper bugs in
resolv.rb which were fixed in the 1.7 branch. I’m reduced to shipping
my software with a version of resolv which I copied from 1.7 and then
hacked to make work with 1.6.
Perhaps there’s fame and (virtual) fortune waiting for the person who
steps up and says “I’ll drive the support of the 1.
branch”, and who’ll fight to ensure that the production releases get
their fair share of developer attention.
Cheers
Dave
stable releases: there should be no known problems in a 1.6 branch
that have solutions in a development branch. Instead, it should be the
norm that developers cannot introduce a solution into the development
tree before they have first solved the problem in the stable branch.
I’d love this to happen.
Perhaps there’s fame and (virtual) fortune waiting for the person who
steps up and says "I’ll drive the support of the 1.
The Perl community has the Perl Foundation, and I believe the Python
community have something similar. Is it time to think of a
non-profit body for Ruby that can organise finances to get important
work like this done? Would such a company/charity/… ease the
transition into corporate environments, because management would see
a corporation from whom they were buying code/support/…?
Dave
Hugh
···
On Thu, 15 Aug 2002, Dave Thomas wrote:
Johan Holmberg holmberg@iar.se writes:
If the 1.7 line is becoming the de-facto version people
are using, I think the handling of releases should be be more
"formal", so Andy can base his installer on a "real" release.
This is the problem, rather than the solution.
We should not be seeing known problems being fixed only in the
development branch. If as a community we are serious about seeing Ruby
in widespread use, then we need to put priority into supporting the
stable releases: there should be no known problems in a 1.6 branch
that have solutions in a development branch. Instead, it should be the
norm that developers cannot introduce a solution into the development
tree before they have first solved the problem in the stable branch.
This is a serious issue. […]
I completely agree (but I didn’t dare to suggest such a great change
myself … )
But when will we see any change, if the developers of Ruby shy away
from this issue (as it seems) ?
Questions about 1.6 vs. 1.7 (and sometimes the CVS version) show up
quite often on this mailing-list, but I haven’t yet seen any clear
statement of the “policies” of the respective code-lines.
In my current project, I’m using 1.6.7. I feel this is prudent.
However, 1.6.7 has two showstopper bugs in resolv.rb which were
fixed in the 1.7 branch.
The thing that has concerned me most has been the impossibly slow IO
in the 1.6 releases (about 50 times slower in 1.6.7 than in 1.7.2
on Windows). I asked for the first time about this in december 2001,
and one of the answers was:
We’ve already known this fact, and fixed it on Ruby 1.7
That is about eight month ago, and seems like an “eon” in these
Internet days …
Please, couldn’t any of the developers of Ruby comment on the
principal issues raised in this thread ?
- the policies for the 1.6 and 1.7 code-lines ?
- the handling of bugs in 1.6.x
(especially those already solved in 1.7 ) ?
- the handling of releases of 1.7.x ?
- the basic support for Ruby on Windows
/Johan Holmberg
···
On Thu, 15 Aug 2002, Dave Thomas wrote: