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
- 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
>
