| Solutions |
Re-use the ruby1.9 source package |
New ruby1.9.1 source package, co-installable with the ruby1.9(.0) packages |
| Source package name |
ruby1.9 |
ruby1.9.1 |
| Binary packages names |
ruby1.9, libruby1.9, etc. |
ruby1.9.1, libruby1.9.1, etc. |
| Interpreter executable |
/usr/bin/ruby1.9 |
/usr/bin/ruby1.9.1 |
| How will the user run scripts? |
ruby1.9 foo.rb for 1.9.0 or 1.9.1, depending on the package installed |
ruby1.9 foo.rb for 1.9.0, ruby 1.9.1 foo.rb for 1.9.1 |
| Transition for users from 1.9.0 (current unstable version) to 1.9.1 |
1.9.1 will replace 1.9.0 |
1.9.1 can be co-installed with 1.9.0 (similar to kernel versions) |
| Third-party library transitions (packaged) |
Installating the 1.9.1 version of ruby1.9 will break all the 1.9.0 library packages. They will have to be transitionned to install files in the right place (/usr/lib/ruby/1.9.1). Question: should we add a Breaks: field in the libruby1.9 package for 1.9.1? |
Installing ruby1.9.1 won't break the 1.9.0 libraries, which will continue to work with Ruby 1.9.0. But libraries still have to be transitioned to 1.9.1. |
| Third-party library transitions (manually installed via setup.rb or extconf.rb) |
Installating the 1.9.1 version of ruby1.9 will break all the manually installed 1.9.0 library packages (which were installed in 1.9.0 dirs). The user will have to re-install them. |
The libraries will continue to be usable with ruby 1.9.0 (using ruby1.9 foo.rb). To use them with 1.9.1, the user will need to re-install them. |
| Third-party library transitions (installed using gems) |
Same status as third-party libs installed manually, since gems are installed in /var/lib/gems/1.9.X/ |
| What about ruby 1.9.2 ? Ruby 1.9.2 is supposed to be API/ABI compatible with ruby 1.9.1 (which means that its loadpath is supposed to stay the same) |
The same ruby1.9 source package will be updated to 1.9.2 |
We can switch to a ruby1.9.2 source package (for consistency) which will Conflict, Replace, Provide the ruby1.9.1 package. Or we can re-use the ruby1.9.1 source package with 1.9.2 binary packages (since that's hidden for the user). Or we can re-use the 1.9.1 source package with 1.9.1-named but really 1.9.2 binary packages, just to avoid going through NEW. |
| What about ruby-support (automatic support of several ruby versions for pure-ruby libs) |
ruby-support would still be useful. Once packages are transitioned to r-s, they will no longer require manual intervention to support new ruby versions |
r-s will allow to automatically support all the installed ruby versions for pure-ruby libs |
| What about squeeze? |
In squeeze, we will release Ruby 1.9.x (x likely to be 2). there will only be one ruby1.9 source package. |
In squeeze, it would be much better to release only one ruby1.9.x package (likely ruby1.9.2). We will need to make sure that ruby1.9.1 and ruby1.9 can safely be removed (not too hard if many libs transition to ruby-support) |
| What about the "ruby" command? |
This is an orthogonal issue, since the ruby command is provided by the ruby-defaults source package. At some point, we will decide to switch to ruby 1.9.x for the ruby command (currently ruby 1.8). Another option could be to use alternatives so that the user can decide (but no consensus on this ; the problem is that many applications use /usr/bin/ruby, and might break). |
| OK, how does our TODO list look like? |
- Upload ruby1.9 1.9.1.x to sid.
- File RC bugs on all packages providing 1.9.0 libs (~40 packages)
- Transition all those packages to 1.9.1 (through ruby-support, if it is ready, or manually)
|
- Upload ruby1.9.1 1.9.1.x to sid.
- Alternatively:
- Wait until ruby-support is really ready, then transition pure-ruby packages to ruby-support (win: automatically support 1.9.0 and 1.9.1
- Transition packages providing 1.9.0 libs to 1.9.1
(we could decide on a per-package basis, users will be able to install libs with gems anyway)
- Remove ruby1.9 source package (providing 1.9.0)
|
| Major pros |
- Simpler for the ruby interpreter maintainers (only one 1.9 source package to maintain)
|
- User can choose between 1.9.0 and 1.9.1
- No breakage for the user (1.9.0 libs continue to work during the transition)
- Third-party libraries can wait until ruby-support is ready
- Less pressure on the library packagers: less urgency to transition libs
|
| Major cons |
- Massive breakage of third-party libs
- Mass transition of third-party
- If done now, ruby-support is not ready => need to transition again for ruby-support
|
- User will end-up with 1.9.0 and 1.9.1 both installed. Needs cleanup at some point (similar to kernel packages).
- Need to maintain two 1.9.x versions in testing/unstable for some time
- Need to go through NEW
|