2016-10-25 14:20 GMT+02:00 Esteban Lorenzano <[email protected]>: > and I will paste Stef’s clarification, because it seems my text was a bit > obscure :) > > Pharo 6.0 will be with the old process. > - no bootstrap > - no git > - 64 bits > So Pharo 6 will be 64 bits?
Yes! Thierry > - stabilisation > > But in parallel to Pharo 6.0 beta we will start Pharo7.0prealpha. > - with bootstrap > - process based on git > The idea is to have some months to get Pharo 70 alpha ready with the new > process > when Pharo 60 gets out (or at least to get some cycles) > > > > On 25 Oct 2016, at 14:19, Esteban Lorenzano <[email protected]> wrote: > > > > Time to send this to dev list: > > (btw, this has to do with what we are going to talk today in TechTalk). > > > > Hi, > > > > Last week we had a meeting where we tried to define current Pharo 6 > efforts and the next Pharo 7 goals (in particular, how to revamp our > process into something that fits better our numbers of today). > > > > The thing is there was no clear roadmap for Pharo 6 and we wanted to > precise it. > > Also, during last years we put some pieces in place and we are ready to > do the next big step (changing the Pharo process) but we need to work hard > until we have it working (and we just have a draft of how we would want to > work, I will talk about later), and we need to discuss, test, iterate > before is working properly. > > > > Anyway, this is what we think: > > > > We need to put Pharo 6.0 development in “feature freeze status” right > now. Only things that needs to enter is: > > - Clements changes (full blocks, SISTA bytecode set, …) > > - 64bits > > - Bugfixes > > > > This way we can jump to work on the new process, that we think will take > some months until we have it ready. > > > > NEW PROCESS: > > > > 1) Builds will be bootstrap based. > > This implies a change of mindset: pharo will be considered as a small > kernel plus a set of maintained packages. This is important to remark > because is a difference in our way of think: until now pharo is “the > image”, now it will be different because there is the possibility of build > different images starting from the kernel and bootstrapping other packages. > > But of course, the standard-distributed image will be still a compound > of the maintained packages (and tests will be ran against this amalgam to > be sure everything continues working) > > > > 2) Sources will be moved to git. > > Concrete structure is TBD, but it will be an unique project (no > submodules) for a start. This is because is hard to handle changes in > multiple submodules… > > Anyway I would like to have different source directories (to separate > kernel from maintained packages :P) > > > > 3) Changes will be managed through Pull Requests (yay!) > > And of course there will be a validation process (travis based)… > > - I’m also thinking on push the built images into some place for people > to be able to verify their errors in the built image (also we could do > this)… I mean, the build images for validation… of course the “integrated” > images will be pushed allways. > > > > This implies a lot of work to make it work, build the tools we need and > make us feel confortable with it, that’s why we want to start as soon as > possible. > > This way, when 7.0 starts in march, we are with the new process. > > > > So that. > > > > Opinions, suggestions? > > > > Esteban > > > > >
