1 |
On Mon, 2011-06-27 at 16:52 -0400, Mike Frysinger wrote: |
2 |
> On Monday, June 27, 2011 12:00:19 Dirkjan Ochtman wrote: |
3 |
> > On Mon, Jun 27, 2011 at 17:53, Petteri Räty <betelgeuse@g.o> wrote: |
4 |
> > > I like the ruby approach for the reason that it doesn't require users to |
5 |
> > > run update scripts like python-updater. |
6 |
> > |
7 |
> > Sure, but if that means the developers now have to bump every package |
8 |
> > in the tree when a new version of Python comes out, I'm not sure |
9 |
> > that's the best trade-off. |
10 |
> |
11 |
> if that's the requirement, i'd lean towards the python route we have today. |
12 |
> especially because python-updater will hit all necessary packages where-as |
13 |
> ruby will often not as that requires you to do `emerge -u <all installed |
14 |
> packages>`. |
15 |
|
16 |
This approach works for ruby because we have multiple implementations |
17 |
(e.g. jruby, hopefully rubinius soon) rather than just multiple |
18 |
versions, and because major version updates that break compatibility are |
19 |
rare. Bumping happens more often than new versions or implementations |
20 |
come out, and we can't expect implementations to be fully compatible. |
21 |
Note that minor versions (ruby 1.8.6 vs ruby 1.8.7) are usually backward |
22 |
compatible, so we can just swap these in within the slot. |
23 |
|
24 |
I don't really see how a ruby-updater tool would work, so the approach |
25 |
we've taken works for ruby. |
26 |
|
27 |
Hans |