> On 22 Mar 2015, at 22:56, Dale Henrichs <[email protected]> > wrote: > > Damien, > > I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello > against Pharo1.1 ... I would use zeroconf with 1.3 but there is something > funkily different between what is available on zeroconf for 1.3 and what > actually "works" for for 1.3 > (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip).
why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) this “forever backward compatibility” ends up being really complicated. I want to deprecate zeroconf for, at least, all pharo < 2.0. why? because the scripts right now downloads one unique vm for all images. Which means download of sources V1, V2, V3… and starting next month V4. I want to remove at least one of those sources. Also… the upcoming spur VM will add another level of complexity to zeroconf scripts (because is everything goes smooth, Pharo5 will dispatch with spur, without backward compatibility). So it will be another V5 + the different VM… What to do with those scripts? maybe deprecate the “vm” part, and replace it for: /vm1 /vm2 /vm3 /vm4 /vmN … and /vm downloading the latest stable (/vm4, next month) but then… what to do with the /30+vm /40+vm scripts? yes… they *could* realise link is talking to “convenient vm” so it would download /vm3 and /vm4… but I’m describing the problem, who grows exponentially. Keeping “forever compatibility” is not good. It does not work. It does not scale. Esteban > Dale > > On 3/13/15 5:04 AM, Damien Cassou wrote: >> Esteban Lorenzano writes: >> >>> that… is someone using it? >> I think the pharo-users mailing list is more appropriate >> > >
