On Fri, 14 Nov 2008, Luis Lavena wrote: > Right now we have 2 blockers for releasing the final -27 of One-Click:
> - Rake fully compatible with Windows > - Solve some installer issues.
> The installer issues are reported in RubyForge as bugs, and should be > easy to get fixed.
> On the other hand, we are working with Rake developers to fix several > issues introduced in latest releases that affected many Windows users.
It might be worth adding a news item about this sort of thing to the site. This would help people see that the project is still alive. Also, may I suggest that you provide people with some information about how you'd like them to test the candidate release? Obviously the wider usage you get of a candidate the better, but a "sketch" of which parts you really would like people to stress would help: it could give an impression of which bits you consider particularly stable as well, for those reluctant to install a release candidate.
Are there plans for a 1.8.7 release, or are you just waiting for 1.9.1 to come out, and skip 1.8.7?
Is there any prospect of a 64-bit release (for those flavours of Vista that support it)?
If I got some time to help I'd need to know about the tools used to create this, but http://rubyinstaller.rubyforge.org/wiki/wiki.pl?DevDoc says it will be updated soon, and it last was in April. Proof that the team is busy, certainly :-) Updating that would make it easier for people to help you, I think.
> On Fri, 14 Nov 2008, Luis Lavena wrote: > > Right now we have 2 blockers for releasing the final -27 of One-Click:
> > - Rake fully compatible with Windows > > - Solve some installer issues.
> > The installer issues are reported in RubyForge as bugs, and should be > > easy to get fixed.
> > On the other hand, we are working with Rake developers to fix several > > issues introduced in latest releases that affected many Windows users.
> It might be worth adding a news item about this sort of thing to the > site. This would help people see that the project is still alive. > Also, may I suggest that you provide people with some > information about how you'd like them to test the candidate release? > Obviously the wider usage you get of a candidate the better, but a > "sketch" of which parts you really would like people to stress would > help: it could give an impression of which bits you consider > particularly stable as well, for those reluctant to install a > release candidate.
Guilty of charge.
Basically the update boosted 1.8.6 to patchlevel 287, which included all the "security patches" that make nervous everybody a few months ago.
It also included updated version of RubyGems, but at that time was 1.2.0, after that 1.3.0 was released and was broken on Windows, which I missed the release deadline and generated some issues for the few users upgraded.
The last piece of the puzzle was Rake, which added some things that broke most of the shell calls. I'm working with the Rake developers and contributors to see these things and came up with something that works for One-Click, Jruby and others.
> Are there plans for a 1.8.7 release, or are you just waiting for 1.9.1 > to come out, and skip 1.8.7?
No plans for 1.8.7, even with 1.8.6-p287 had weird results for things like ParseTree, which is important for several projects that depend on.
Plans for 1.9 are contemplated but not for the current One-Click codebase. Bundling everything makes difficult differentiate ruby from the packages that need to be tested for compatibility.
You can check here the list of packages included in RC1:
There are no plans for 64bits for current installer, since it depends on this VC6 builds.
The 64bits available builds are for 1.9, but those depends on VC8, something we are trying to avoid and move to MinGW (GCC) to reduce the discrepancies across platforms for the build process (not only of ruby but extensions and other projects).
mingw-w64 will provide the building blocks, it can cross-compile from 32bits OS targeting 64bits
My installed OS base is 32bits XP, with only one x64 XP edition available, and cannot book that resource for OpenSource projects at this time.
> If I got some time to help I'd need to know about the tools used to > create this, buthttp://rubyinstaller.rubyforge.org/wiki/wiki.pl?DevDoc > says it will be updated soon, and it last was in April. Proof that > the team is busy, certainly :-) Updating that would make it easier > for people to help you, I think.
To work on current installer, these docs are up to date. To work on the new installer, the docs are in the readme document at github:
With the new installer we found issues that make difficult build different versions of the same package (on which Ruby depends like readline, zlib, and others).
Work on this new building process has made some progress the past days:
> Plans for 1.9 are contemplated but not for the current One-Click > codebase. Bundling everything makes difficult differentiate ruby from > the packages that need to be tested for compatibility.
What should I recommend to PickAxe readers? I'm planning to ship the book when 1.9.1 is stable, and I'd like to give them good advice.
On Nov 15, 1:36 am, Dave Thomas <d...@pragprog.com> wrote:
> On Nov 14, 2008, at 4:32 PM, Luis Lavena wrote:
> > Plans for 1.9 are contemplated but not for the current One-Click > > codebase. Bundling everything makes difficult differentiate ruby from > > the packages that need to be tested for compatibility.
> What should I recommend to PickAxe readers? I'm planning to ship the > book when 1.9.1 is stable, and I'd like to give them good advice.
As you may know One-Click bundles almost the world in Rubyland. Some of the things bundled has not been updated (by the project developers) since 2006 and are still bundled "for compatibility with previous releases".
Doing a release for 1.9 series requires review of all those packages, some not being updated for 1.9 and others that lacks complete set of testing setup that can ease the process of review.
The work on RubyInstaller (Ruby+RubyGems) based on MinGW is about to cover both 1.8 and 1.9. Since it will not be shipped with any other gem or extension, is under user control to be able to download these for 1.9.
The binaries from garbagecollect for 1.9 can be easily used just adding the missing dlls for some of the extensions (like openssl or zlib). Yet still it depends on VC6 and some of the gems, extensions and libraries from current Installer will not work.
I guess lot of people will complain about this, but is the healthy option at this time (I'm open to suggestions, of course).
> Can I suggest you make more "noise" about this, please? It needs to > get out on the Rubyforge site, on the Wiki, and elsewhere. This is > a serious problem affecting open source and community based software, > and those who object to this model of development have a strong case > when they speak of "abandonware".
One simple suggestion. Change RubyGems in 1.9 so the default value for required_ruby_version is '< 1.9'
Then, existing gems that don't have an explicit value for this (which is probably 99% of them) will not even try to load on 1.9. Their maintainers can at some point test them with 1.9 and then add the required_ruby_version line which will make them work again (with both 1.8 and 1.9).
This will also help rubyforge—it can display a 1.9 icon next to gems that have the appropriate Ruby version set, allowing both users and maintainers to see what's what.
> > Can I suggest you make more "noise" about this, please? It needs to > > get out on the Rubyforge site, on the Wiki, and elsewhere. This is > > a serious problem affecting open source and community based software, > > and those who object to this model of development have a strong case > > when they speak of "abandonware".
> One simple suggestion. Change RubyGems in 1.9 so the default value for > required_ruby_version is '< 1.9'
> Then, existing gems that don't have an explicit value for this (which > is probably 99% of them) will not even try to load on 1.9. Their > maintainers can at some point test them with 1.9 and then add the > required_ruby_version line which will make them work again (with both > 1.8 and 1.9).
> This will also help rubyforge—it can display a 1.9 icon next to gems > that have the appropriate Ruby version set, allowing both users and > maintainers to see what's what.
Would you please bring this subject to rubygems-devel mailing list?
I believe you have a point, but both Eric Hodel (maintainer) and Tom Copeland (RubyForge) can provide more details about current situation than I can do.
In any case, no more bundling will be present in new One-Click Installer, but different packages will be generated (more details to come).
