Discussion:
QUESTION: Is anybody using zeroconf with Pharo 2.0?
(too old to reply)
Esteban Lorenzano
2015-03-12 14:16:47 UTC
Permalink
that… is someone using it?

cheers,
Esteban
Damien Cassou
2015-03-13 12:04:09 UTC
Permalink
Post by Esteban Lorenzano
that… is someone using it?
I think the pharo-users mailing list is more appropriate
--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Dale Henrichs
2015-03-22 21:56:03 UTC
Permalink
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).

Dale
Post by Damien Cassou
Post by Esteban Lorenzano
that… is someone using it?
I think the pharo-users mailing list is more appropriate
Marcus Denker
2015-03-23 06:46:33 UTC
Permalink
Post by Dale Henrichs
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).
I do not think that this is a good idea: we are not building a Museum.
For example, we improve the core libraries. It will make something like Metacello *very* complex to be compatible over so many versions back.
In the end, people who have this philosophy start to even request “to make this easier”, and then tell us to stop changing.

Make your live easier and do *not* support old versions! Everything gets easier and the world will be a happier place.

Marcus
Dale Henrichs
2015-03-23 16:16:31 UTC
Permalink
I still have production code (GemTools) that runs today in Pharo 1.1 ...

I assume that others also have production code running in older versions
of Pharo and Squeak and GemStone so I make sure that Metacello continues
to work on those platforms ...

Not everyone has the luxury of having the time to port their entire
production catalog to the latest version of Pharo ...

I don't demand that zeroconf support Pharo1.2 as long as there is a way
that I can keep downloading Pharo1.2 ... but if you don't intend to
support all releases of Pharo on zeroconf, then I will simply start
using the alternate long term method in my scripts because I certainly
don't want to have to change scripts that are working perfectly fine,
because you've decided to drop support for a particular version....

Dale
Post by Marcus Denker
Post by Dale Henrichs
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).
I do not think that this is a good idea: we are not building a Museum.
For example, we improve the core libraries. It will make something like Metacello *very* complex to be compatible over so many versions back.
In the end, people who have this philosophy start to even request “to make this easier”, and then tell us to stop changing.
Make your live easier and do *not* support old versions! Everything gets easier and the world will be a happier place.
Marcus
Marcus Denker
2015-03-23 16:20:58 UTC
Permalink
Post by Dale Henrichs
I still have production code (GemTools) that runs today in Pharo 1.1 ...
I assume that others also have production code running in older versions of Pharo and Squeak and GemStone so I make sure that Metacello continues to work on those platforms ...
Not everyone has the luxury of having the time to port their entire production catalog to the latest version of Pharo ...
I don't demand that zeroconf support Pharo1.2 as long as there is a way that I can keep downloading Pharo1.2 ... but if you don't intend to support all releases of Pharo on zeroconf, then I will simply start using the alternate long term method in my scripts because I certainly don't want to have to change scripts that are working perfectly fine, because you've decided to drop support for a particular version….
Even Microsoft does not support ever old version of Windows. How can we?
Wouldn’t it get indefinitely expensive?

Marcus
Dale Henrichs
2015-03-23 16:34:52 UTC
Permalink
Did I ask for support?

I asked to be able to continue to be able to continue to download older
versions of Pharo.

If you say no, then you say no.

If you intend to cutoff the downloads for older versions of Pharo, then
I would ask that you give me a couple of months warning.

If you say no, then you say no.

The original question was ... "Is anyone using zerconf for Pharo2.0" and
I answered your question...

I'm not sure that it costs you anything (other than goodwill) by
allowing folks to download older versions of Pharo ...

Supporting older versions of Pharo is another kettle of fish ...

Dale
Post by Marcus Denker
Post by Dale Henrichs
I still have production code (GemTools) that runs today in Pharo 1.1 ...
I assume that others also have production code running in older versions of Pharo and Squeak and GemStone so I make sure that Metacello continues to work on those platforms ...
Not everyone has the luxury of having the time to port their entire production catalog to the latest version of Pharo ...
I don't demand that zeroconf support Pharo1.2 as long as there is a way that I can keep downloading Pharo1.2 ... but if you don't intend to support all releases of Pharo on zeroconf, then I will simply start using the alternate long term method in my scripts because I certainly don't want to have to change scripts that are working perfectly fine, because you've decided to drop support for a particular version….
Even Microsoft does not support ever old version of Windows. How can we?
Wouldn’t it get indefinitely expensive?
Marcus
Esteban Lorenzano
2015-03-23 08:06:52 UTC
Permalink
Post by Dale Henrichs
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
Post by Dale Henrichs
Dale
Post by Damien Cassou
Post by Esteban Lorenzano
that… is someone using it?
I think the pharo-users mailing list is more appropriate
Max Leske
2015-03-23 08:16:00 UTC
Permalink
Post by Esteban Lorenzano
Post by Dale Henrichs
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 am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (don’t judge… :) ). But I don’t need the zero conf scripts for those.
Post by Esteban Lorenzano
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?
/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
Post by Dale Henrichs
Dale
Post by Damien Cassou
Post by Esteban Lorenzano
that… is someone using it?
I think the pharo-users mailing list is more appropriate
Tudor Girba
2015-03-23 08:17:48 UTC
Permalink
Hi,
Post by Dale Henrichs
Post by Esteban Lorenzano
On 22 Mar 2015, at 22:56, Dale Henrichs <
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).
Post by Esteban Lorenzano
why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with
the exception of some legacy apps)
Post by Esteban Lorenzano
this “forever backward compatibility” ends up being really complicated.
I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (don’t judge
 :) ).
I do not judge. I pity :))

Doru


But I don’t need the zero conf scripts for those.
Post by Dale Henrichs
Post by Esteban Lorenzano
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.
Post by Esteban Lorenzano
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

Post by Esteban Lorenzano
What to do with those scripts?
/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.
Post by Esteban Lorenzano
Keeping “forever compatibility” is not good.
It does not work.
It does not scale.
Esteban
Dale
Post by Damien Cassou
that
 is someone using it?
I think the pharo-users mailing list is more appropriate
--
www.tudorgirba.com

"Every thing has its own flow"
Marcus Denker
2015-03-23 08:24:18 UTC
Permalink
Post by Dale Henrichs
Hi,
Post by Esteban Lorenzano
Post by Dale Henrichs
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 <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 am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (don’t judge
 :) ).
I do not judge. I pity :))
It is ok to use them, but people should not expect that packages and framework will be updated.
(and this even defeats the purpose: people use old version *becasue they do not want change*.

If we update stuff under their feet (Zinc, Metacello
) this will lead to exactly what they do not want.

We should consider old version to be frozen, *including* the frameworks and tools.

Marcus
Sven Van Caekenberghe
2015-03-23 08:26:58 UTC
Permalink
Post by Marcus Denker
Post by Max Leske
Hi,
Post by Esteban Lorenzano
Post by Dale Henrichs
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 am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (don’t judge… :) ).
I do not judge. I pity :))
It is ok to use them, but people should not expect that packages and framework will be updated.
(and this even defeats the purpose: people use old version *becasue they do not want change*.
If we update stuff under their feet (Zinc, Metacello…) this will lead to exactly what they do not want.
We should consider old version to be frozen, *including* the frameworks and tools.
Marcus
I agree.

It is of course up to each developer to decide how far back they want to support their code.

But indeed, the reason to stay with an old(er) version is because you do not want change.

Sven
Dale Henrichs
2015-03-23 16:42:24 UTC
Permalink
Marcus,

Frozen and downloadable is absolutely fair and not unexpected ...

It would be convenient if zeroconf continued to work for the frozen
products, but if that isn't practical for you then I can live with
that...as long as I can continue to download for testing of Metacello on
travis:)

Dale
Post by Marcus Denker
Post by Dale Henrichs
Hi,
On 23 Mar 2015, at 09:06, Esteban Lorenzano
On 22 Mar 2015, at 22:56, Dale Henrichs
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 am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (don’t judge
 :) ).
I do not judge. I pity :))
It is ok to use them, but people should not expect that packages and
framework will be updated.
(and this even defeats the purpose: people use old version *becasue
they do not want change*.
If we update stuff under their feet (Zinc, Metacello
) this will lead
to exactly what they do not want.
We should consider old version to be frozen, *including* the
frameworks and tools.
Marcus
Dale Henrichs
2015-03-23 16:38:48 UTC
Permalink
I don't need zeroconf for my Pharo1.1 app, either. Alternate download
methods would be fine.

I continue to support Metacello on all of the older versions of Pharo
and I do use zeroconf there, but if there is an alternate download
mechanism then I can use that for testing ...

Dale
Post by Max Leske
Post by Esteban Lorenzano
Post by Dale Henrichs
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 am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (don’t judge… :) ). But I don’t need the zero conf scripts for those.
Post by Esteban Lorenzano
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?
/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
Post by Dale Henrichs
Dale
Post by Damien Cassou
Post by Esteban Lorenzano
that… is someone using it?
I think the pharo-users mailing list is more appropriate
Marcus Denker
2015-03-23 16:43:11 UTC
Permalink
I don't need zeroconf for my Pharo1.1 app, either. Alternate download methods would be fine.
I continue to support Metacello on all of the older versions of Pharo and I do use zeroconf there, but if there is an alternate download mechanism then I can use that for testing 

Download will be available eternally:

http://files.pharo.org/image/ <http://files.pharo.org/image/>
http://files.pharo.org/vm/ <http://files.pharo.org/vm/>

Marcus
Marcus Denker
2015-03-23 16:50:00 UTC
Permalink
Post by Marcus Denker
I don't need zeroconf for my Pharo1.1 app, either. Alternate download methods would be fine.
I continue to support Metacello on all of the older versions of Pharo and I do use zeroconf there, but if there is an alternate download mechanism then I can use that for testing 

http://files.pharo.org/image/ <http://files.pharo.org/image/>
http://files.pharo.org/vm/ <http://files.pharo.org/vm/>
The thing is that get.pharo.org <http://get.pharo.org/> is more than a download. People will expect that it *works*. And we can not (we really can not) support all versions
of Pharo. E.g. Spur. Soon we will have a VM that can not run old images. If we keep get.pharo.org <http://get.pharo.org/> for 1.4, people expect it to work. And we will have
to provide a VM for the old version. Then at some point, this VM will not work anymore on the then current linux. Then people expect us to fix that.

Just downloads is a different thing: this is an archive, use it at your own risk.

Marcus
Dale Henrichs
2015-03-23 17:12:22 UTC
Permalink
Marcus,

This makes perfect sense to me ... If zeroconf is only used for the
supported versions of Pharo that is perfectly fair ...

When a version goes off of zeroconf support it would be convenient if
one could find the appropriate "eternal download urls" for the image/vm
otherwise how would I know?

Keep in mind, that I use zeroconf to download for travis-based tests and
I don't have a physical disk to look at ... and it is possible that I
won't know that a particular version has gone off of zeroncof support
until my build fails ... so it would be _convenient_ to be able to
lookup the image/vm combo that I need to use...

Dale
The thing is that get.pharo.org <http://get.pharo.org> is more than a
download. People will expect that it *works*. And we can not (we
really can not) support all versions
of Pharo. E.g. Spur. Soon we will have a VM that can not run old
images. If we keep get.pharo.org <http://get.pharo.org> for 1.4,
people expect it to work. And we will have
to provide a VM for the old version. Then at some point, this VM will
not work anymore on the then current linux. Then people expect us to
fix that.
Just downloads is a different thing: this is an archive, use it at your own risk.
Marcus
Esteban Lorenzano
2015-03-23 19:21:43 UTC
Permalink
Yes
 I was asking to see how can we proceed, because we cannot continue distributing as now.
In the course of the conversation I found a solution that will please everyone
 and will allow us to keep giving also zeroconf scripts without needing to download source versions for all (which was, in fact, the problem I was trying to fix).
It will require some file reorganisation and the concept of “blessed vm”: a version we will distribute with the image version (it will be a vm for pharo1, one for pharo2, etc
 each one with their sources

And yes
 that means a bit more work to configure if you have multiple image-versions
 but in the long way is the only way we can ensure how an image and a vm works together :)

So, no need to continue arguing :)

cheers,
Esteban
Post by Dale Henrichs
Marcus,
This makes perfect sense to me ... If zeroconf is only used for the supported versions of Pharo that is perfectly fair ...
When a version goes off of zeroconf support it would be convenient if one could find the appropriate "eternal download urls" for the image/vm otherwise how would I know?
Keep in mind, that I use zeroconf to download for travis-based tests and I don't have a physical disk to look at ... and it is possible that I won't know that a particular version has gone off of zeroncof support until my build fails ... so it would be _convenient_ to be able to lookup the image/vm combo that I need to use...
Dale
Post by Marcus Denker
The thing is that get.pharo.org <http://get.pharo.org/> is more than a download. People will expect that it *works*. And we can not (we really can not) support all versions
of Pharo. E.g. Spur. Soon we will have a VM that can not run old images. If we keep get.pharo.org <http://get.pharo.org/> for 1.4, people expect it to work. And we will have
to provide a VM for the old version. Then at some point, this VM will not work anymore on the then current linux. Then people expect us to fix that.
Just downloads is a different thing: this is an archive, use it at your own risk.
Marcus
Esteban Lorenzano
2015-03-23 13:14:12 UTC
Permalink
well… after sending this mail I stayed thinking and I think something like this is precisely what I have to do :)
so I will do an important change to zeroconf to ensure newer versions do not screw with older ones.

cheers,
Esteban
Post by Esteban Lorenzano
Post by Dale Henrichs
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?
/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
Post by Dale Henrichs
Dale
Post by Damien Cassou
Post by Esteban Lorenzano
that… is someone using it?
I think the pharo-users mailing list is more appropriate
stepharo
2015-03-23 20:25:57 UTC
Permalink
Why do you start fun discussion when I'm not connected :).
I like the idea of the distinction between archive and supported.
I like archives :)

Loading...