[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

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.

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 <[hidden email]> 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 :)

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.

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.
One step at a time.
We do not care if we have double for now.
We should not lose Epicea.

Stef