[ANN] Pharo 6.0 Development started
Hi, So, that: We just started development of Pharo 6.0 :) And of course, now monkey fails because you guys committed fixes from Pharo 6.0 in Pharo 5.0 inbox... so if you want the check, please commit in the new inbox :) cheers! Esteban
Is there a (informal) roadmap for Pharo 6.0? What are the major things that are being targeted? Bloc replacing Morphic? Move from 32-bit to 64-bit? Athens-based rendering? Cheers, Jeff On Fri, May 13, 2016 at 11:31 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
So, that: We just started development of Pharo 6.0 :)
And of course, now monkey fails because you guys committed fixes from Pharo 6.0 in Pharo 5.0 inbox... so if you want the check, please commit in the new inbox :)
cheers! Esteban
On 13/05/2016 18:08, J.F. Rick wrote:
Is there a (informal) roadmap for Pharo 6.0? What are the major things that are being targeted? Bloc replacing Morphic? Move from 32-bit to 64-bit? Athens-based rendering?
Cheers,
Jeff
It would be good to have one to not integrate too many new things like in Pharo 5 and have trouble stabilizing it. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
Cyril Ferlicot wrote:
It would be good to have one to not integrate too many new things like in Pharo 5 and have trouble stabilizing it.
Please define "too many" and "trouble" :P Hey - right after Pharo 4 was release I switch and used Pharo 5 through the whole development cycle even during the "shaky" times. Following the point "Communication is key" in Pharo Zen this was clearly announced to all the contributors. Yes - there was some trouble inbetween and yes it costed us all time and work to switch also to UFFI and others. But Spur now made us faster, UFFI more unified, ...
From my POV Pharo 5 primarily was usable enough even for the ones living (working) on the edge. It's anyones own decision to take the unstable ride during development of next version or stay with the last stable release.
As we all know the only constant in life is change: so we should not fear to change, add or remove when we see it as necessary. The more new and interesting stuff the better. How much "more" really means will be depending on all our contributions which I hope will again increase. Pharo 6 should and will again be better and I hope it will include many new stuff even when things might get shaky again. Step by step it goes... Bye T.
I second Torsten. Even though I had a lot of trouble over the font bug, I'd argue it was more of a problem on my side as I didn't adapt appropriately... after all we still have available all versions of the release. As long as the core devs are ok with the amount of change, I don't see a problem. And if you want to live on the `bleedingEdge`, well then also read the first part of the word. :) So as long as people who create the stuff actually manage it, I'm happy with the bumpy ride because the result is that more amazing. Peter On Fri, May 13, 2016 at 7:09 PM, Torsten Bergmann <astares@gmx.de> wrote:
Cyril Ferlicot wrote:
It would be good to have one to not integrate too many new things like in Pharo 5 and have trouble stabilizing it.
Please define "too many" and "trouble" :P
Hey - right after Pharo 4 was release I switch and used Pharo 5 through the whole development cycle even during the "shaky" times. Following the point "Communication is key" in Pharo Zen this was clearly announced to all the contributors.
Yes - there was some trouble inbetween and yes it costed us all time and work to switch also to UFFI and others. But Spur now made us faster, UFFI more unified, ...
From my POV Pharo 5 primarily was usable enough even for the ones living (working) on the edge. It's anyones own decision to take the unstable ride during development of next version or stay with the last stable release.
As we all know the only constant in life is change: so we should not fear to change, add or remove when we see it as necessary. The more new and interesting stuff the better. How much "more" really means will be depending on all our contributions which I hope will again increase.
Pharo 6 should and will again be better and I hope it will include many new stuff even when things might get shaky again.
Step by step it goes...
Bye T.
Hi Jeff We discussed two weeks ago so from my memory: We should see if we cannot do a 6 months release instead of 12 months. - git support and process (nicolas passerini is working on it) the idea is to have a process (not just a command line) that helps us managing cross projects changes - bootstrap pavel, christophe and guille are working on it - Cargo package manager christophe should release a version soon - Epicea - cleaning tools, cleaning spec, ProtoObject, - being able to remove the old compiler and reload it - improving the coverage of the core bootstrap - removing useless stuff (newList, TextHolder...) - Probably 64 bits For Bloc it also depends on Brick. stef
On 14 May 2016, at 14:59, stepharo <stepharo@free.fr> wrote:
Hi Jeff
We discussed two weeks ago so from my memory:
We should see if we cannot do a 6 months release instead of 12 months.
as it is now is just not possible. It took Marcus and me two full weeks of working on boring details and now Iâm fried (and I know Marcus is too)⦠now, we need to change the process so we can do this easier, then yes we can release more frequently :)
- git support and process (nicolas passerini is working on it) the idea is to have a process (not just a command line) that helps us
managing cross projects changes
- bootstrap pavel, christophe and guille are working on it
- Cargo package manager christophe should release a version soon
- Epicea
this would means also (probably) changing from once the sources/changes format⦠now changes keeps a delta too and there is an unnecessary overlap with epicea.
- cleaning tools, cleaning spec, ProtoObject,
- being able to remove the old compiler and reload it
- improving the coverage of the core bootstrap
- removing useless stuff (newList, TextHolder...)
- Probably 64 bits
not just probably⦠this is a strong âmustâ :) also we should not be too far from having it.
For Bloc it also depends on Brick.
yes, most probably we will include block but we would not replace morphic in Pharo 6⦠is too much work and weâll take some more time for stabilising and moving onto it. other issues: - UFFI 2.0 (optimisations, better support for arrays, etc.) - OSWindows will take over the world :) and I think this is enough for a version :) Esteban
stef
as it is now is just not possible. It took Marcus and me two full weeks of working on boring details and now Iâm fried (and I know Marcus is too)⦠now, we need to change the process so we can do this easier, then yes we can release more frequently Tell me I can also do something else during three months per year :) And multiply that by many and we see that once every year is too long.
- git support and process (nicolas passerini is working on it) the idea is to have a process (not just a command line) that helps us
managing cross projects changes
- bootstrap pavel, christophe and guille are working on it
- Cargo package manager christophe should release a version soon
- Epicea
this would means also (probably) changing from once the sources/changes format⦠now changes keeps a delta too and there is an unnecessary overlap with epicea.
One step at a time. We do not care if we have double for now. We should not lose Epicea. Stef
- cleaning tools, cleaning spec, ProtoObject,
- being able to remove the old compiler and reload it
- improving the coverage of the core bootstrap
- removing useless stuff (newList, TextHolder...)
- Probably 64 bits
not just probably⦠this is a strong âmustâ :) also we should not be too far from having it.
For Bloc it also depends on Brick. yes, most probably we will include block but we would not replace morphic in Pharo 6⦠is too much work and weâll take some more time for stabilising and moving onto it.
other issues:
- UFFI 2.0 (optimisations, better support for arrays, etc.) - OSWindows will take over the world :)
and I think this is enough for a version :)
Esteban
stef
participants (6)
-
Cyril Ferlicot Delbecque -
Esteban Lorenzano -
J.F. Rick -
Peter Uhnák -
stepharo -
Torsten Bergmann