Why is there no deprecation for classes? The class definition can belong to a deprecated package. For more advanced feature, the deprected globals could belong to another dictionary, a bit like Undeclared...
Le mer. 27 nov. 2019 à 21:31, ducasse <[email protected]> a écrit : > 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 > > > > > >
