--- Begin Message ---
Stéphane,
You could have said the exact same thing in nicer words, calmly WITHOUT
SHOUTING and taking it personal.
If people criticize stuff/work/code, it's because 1) they care about
Pharo 2) they use Pharo. The day no one will complain on the list will
mean Pharo's dead.
It also means people have to deal with real projects and real apps and
real customers and real migration problems. We have a tool called
deprecation, let's use it. It'll save a lot of headaches to everyone.
And if you remove stuff, give the developers an extra chance by at least
informing them of the upcoming changes/removals by deprecating stuff,
not just removing it without warning!
I don't recall one single instance in my professional life when
VisualWorks or VisualAge Smalltalk didn't provide EVERYTHING that was
necessary to be compatible with the previous version to facilitate the
job of their customers, us, the developers. Whether it was in the form
of deprecated parcels or packages, Cincom & IBM (and now Instantiations)
understood one thing : you don't migrate apps that generate millions a
year like a tic-tac-toe project on GitHub. It takes time just to migrate
from one version to the next, imagine the nightmare when "stuff had just
been removed" out of the blue. If you want to see more commercial use of
Pharo, you'll have to understand that!
In the meantime, could you PLEASE stop taking criticism as if it was
directed towards you and/or the Pharo devs?
On 2019-11-27 15:31, ducasse wrote:
Cyril
there is no deprecation for classes: yes I would have to subclass each class
and provide old classes.
Sorry but *****I******* repackaged, cleaned the tests, cleaned the baseline,
made sure that the baseline is working …. of
- GTRecorder (not used in Pharo since 3 YEARS).
- Enlumineur
And I do not have nor the time or energy at the end of the day to do that in
addition
to do all the deprecation and of course fix all the dependencies tests.
Now if your message is that Pharo should stay with all that shit inside then
perfect, I’m off.
I have plenty of other things (and a lot more exciting to do).
BTW I THE GUY THAT IS PRODUCING MIGRATOR: you see the idiot that is collecting
all the deprecated methods
and packaged them so that OTHERS than me can migrate.
So now for Blueink then you take 5 min and change your scripts.
So GTEvent recorder you ask alex or milton to see if we can get rid of the
problem.
I do not see why Moose is loading Roassal with it.
To me this is a bad dependency of Roassal.
If Pharo puts on itself so much constraints then at the end may be I should
stop and do something and see
how great this super kitchen sink will evolved.
Have you ever dare to look at the BaselineOfPharo, IDE just for the fun.
Yes, this could have been handled much better, I guess (I don't know the
details).
But for day to day work, you have to use Pharo 7, which should be 100% stable,
while Pharo 8 is a moving target, an alpha version that is sometimes broken.
Hi,
I agree that the alpha version does not have to be stable all the
time, but I still don't think it justify to not deprecate things.
When you are working on stable version only, it is still better to be
able to migrate your projects from one version to the other via the
deprecation than to have everything broken and not loadable.
If you can't even load your code, it's much harder to fix it. So I
still think that we should go via deprecations. It has really a low
cost and make migrations so much easier. Especially it give us time
instead of giving us an ultimatum "You want to change of version? Then
you need to fix everything now".
Now, we still want users for Pharo 8, else there will be no feedback, so there
are certainly two sides to this argument.
Sven
--
Cyril Ferlicot
https://ferlicot.fr
--
-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
GitHub: bstjean
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)
--- End Message ---
