Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Marcus Denker]

> On 18 Aug 2017, at 09:56, Marcus Denker  wrote:
> 
>> 
>> What I think would have been good is to list all the updates that where done 
>> between
>> releasing 6.0 and 6.1 *as part of the changelog* of 6.1 (even though they 
>> were already 
>> in the image that you got a minute before Pharo6.1 was released, as they 
>> where released as
>> hot fixes before).
>> 
> 
> The changelog of things done between releasing 6.0 and the release of 6.1:
> 

I added a link to the complete changeling to 
http://pharo.org/news/pharo6.1-released 


Marcus

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Ben Coman]

> Normally you have a CI that builds from the latest pharo image + the
latest commit from your repo and you start with that all couple of
days/weeks (This is important
to make sure that you have a reproduce build, too).

This is expected for production code, but maybe not the workflow for
everyone (e.g. hobbyists or people exploring datasets.)

On Fri, Aug 18, 2017 at 10:36 PM, Marcus Denker 
wrote:

>
> On 18 Aug 2017, at 15:41, Tim Mackinnon  wrote:
>
> If you don’t mind - let me try a second attempt at paraphrasing what you
> are saying (just to make sure I’m clear, but it might help others too).
>
> We start each yearly cycle with an X0 new release (our current release is
> 6). Then there may be point releases 6.1, 6.2 etc where there is a breaking
> change (typically a new VM. Our last point release was 6.1).
>
> Thought the year (typically every few days) there are  “hot fixes” that
> causes an image number change (these have worked there way through the CI,
> and have triggered a new artefect). These images can be found at
> http://files.pharo.org/image/60/ (where 60 designates the last release
> cycle, we don’t use point designations for this directory name).
>
> When you download the latest point release, you are getting all the major
> elements of that release plus any of the hot fixes that have occurred since
> that official release. *So you have the most up to date version of a
> stable Pharo at the time that you download this file from: *
> http://pharo.org/download
>
>
> yes
>
> The implication of the above, is that if you want to revert to exactly
> what was present in the launch of an official point release, you will need
> to download the latest release from Pharo.org  and
> then find the image number that corresponded to that release at
> http://files.pharo.org/image/60/ (is there an easy way to determine this
> and then find that file? Or is there an official archive of the first point
> release?).
>
> If you want to say up to date, you should periodically download the latest
> point release (or you can simply find that latest named image file from:
> http://files.pharo.org/image/60/ and use your current VM).
>
> If the above is the case - it seems like a reasonable way of operating,
> although it might be good to know what the exact image number was in the
> first issued point release (just for traceability).
>
> Have I now got it straight now?
>
> Yes.
> And maybe it is not good… maybe it would be better to accumulate the
> changes between the point release without changing the download and have
> the version numbers
> more prominent in the downloaded files (so that it is easy to find old
> versions, too).
>

For major.minor.hotfix versioning, maybe the hotfixes that pass CI could
accumulate in a list that is loaded similar to the old System > Software
Update method,
so hotfixes are available without without having to throw away an image -
i.e. a new download is only required for a "major.minor" update.

A user might individually select a hotfix, but the default list gives a
standard order to load them.  Each change to that default list is
essentially a ".hotfix" point release.   This may provide the mechanism to
provide more longevity of Pharo versions. As part of their CI, anyone can
download the major.minor release and then the default hotfix list (or their
own list).  Older Pharo versions would tend to become more
community-supported.

cheers -ben

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Esteban Lorenzano]

> On 18 Aug 2017, at 14:53, Marcus Denker  wrote:
> 
> The problem is that doing a release 6.1 takes half a day of work. We could 
> improve that, but then with Pharo7 all this changed anyway, so we will not 
> improve this process.
> 

half day? apply murphy law for system estimation: 

- raise measure unit by one: day=week
- double time: 1/2 = 1

it took me one week to deliver the 6.1 release :(

this is something we will be fixing with 7.0 process: each image would be like 
a final image, then we will be able (or we *should* be able)  to create a new 
release by just changing a file and pushing it.

Esteban

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Marcus Denker]

> On 18 Aug 2017, at 15:41, Tim Mackinnon  wrote:
> 
> If you don’t mind - let me try a second attempt at paraphrasing what you are 
> saying (just to make sure I’m clear, but it might help others too).
> 
> We start each yearly cycle with an X0 new release (our current release is 6). 
> Then there may be point releases 6.1, 6.2 etc where there is a breaking 
> change (typically a new VM. Our last point release was 6.1).
> 
> Thought the year (typically every few days) there are  “hot fixes” that 
> causes an image number change (these have worked there way through the CI, 
> and have triggered a new artefect). These images can be found at 
> http://files.pharo.org/image/60/  (where 60 
> designates the last release cycle, we don’t use point designations for this 
> directory name).
> 
> When you download the latest point release, you are getting all the major 
> elements of that release plus any of the hot fixes that have occurred since 
> that official release. So you have the most up to date version of a stable 
> Pharo at the time that you download this file from: http://pharo.org/download 
>  
> 

yes

> The implication of the above, is that if you want to revert to exactly what 
> was present in the launch of an official point release, you will need to 
> download the latest release from Pharo.org  and then find 
> the image number that corresponded to that release at  
> http://files.pharo.org/image/60/  (is there 
> an easy way to determine this and then find that file? Or is there an 
> official archive of the first point release?).
> 
> If you want to say up to date, you should periodically download the latest 
> point release (or you can simply find that latest named image file from:  
> http://files.pharo.org/image/60/  and use 
> your current VM).
> 
> If the above is the case - it seems like a reasonable way of operating, 
> although it might be good to know what the exact image number was in the 
> first issued point release (just for traceability).
> 
> Have I now got it straight now?
> 
Yes.
And maybe it is not good… maybe it would be better to accumulate the changes 
between the point release without changing the download and have the version 
numbers
more prominent in the downloaded files (so that it is easy to find old 
versions, too).

With Pharo7 we can improve this...

Marcus

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Tim Mackinnon]

If you don’t mind - let me try a second attempt at paraphrasing what you are 
saying (just to make sure I’m clear, but it might help others too).

We start each yearly cycle with an X0 new release (our current release is 6). 
Then there may be point releases 6.1, 6.2 etc where there is a breaking change 
(typically a new VM. Our last point release was 6.1).

Thought the year (typically every few days) there are  “hot fixes” that causes 
an image number change (these have worked there way through the CI, and have 
triggered a new artefect). These images can be found at 
http://files.pharo.org/image/60/  (where 60 
designates the last release cycle, we don’t use point designations for this 
directory name).

When you download the latest point release, you are getting all the major 
elements of that release plus any of the hot fixes that have occurred since 
that official release. So you have the most up to date version of a stable 
Pharo at the time that you download this file from: http://pharo.org/download 
 

The implication of the above, is that if you want to revert to exactly what was 
present in the launch of an official point release, you will need to download 
the latest release from Pharo.org  and then find the image 
number that corresponded to that release at  http://files.pharo.org/image/60/ 
 (is there an easy way to determine this and 
then find that file? Or is there an official archive of the first point 
release?).

If you want to say up to date, you should periodically download the latest 
point release (or you can simply find that latest named image file from:  
http://files.pharo.org/image/60/  and use 
your current VM).

If the above is the case - it seems like a reasonable way of operating, 
although it might be good to know what the exact image number was in the first 
issued point release (just for traceability).

Have I now got it straight now?

Tim

> On 18 Aug 2017, at 13:53, Marcus Denker  wrote:
> 
> 
>> On 18 Aug 2017, at 13:08, Tim Mackinnon > > wrote:
>> 
>> Thanks Marcus - and definitely we all appreciate that its holiday season and 
>> that a lot of this is driven by community and people donating their free 
>> time.
>> 
>> I’m still a bit unclear on the moving parts. To paraphrase what you have 
>> said:
>> 
>> We start each yearly cycle with a X.0 new release. Then there may be point 
>> releases 6.1, 6.2 etc where there is a breaking change (typically a new VM I 
>> guess - but is there anything else that would cause a .x release?).
>> 
>> Then there are  “hot fixes” that causes an image number change (these have 
>> worked there way through the CI, as it triggered a new build)? The 
>> implication is then that what I download from Pharo.org  
>> is the last point release,
> 
> No, the download is always the latest (with all accepted fixes integrated).
> 
>> but then I can go and find a newer image “hot fix” if I want some of the 
>> latest more minor fixes (and I guess this then answers m .x question above - 
>> as I guess that if there was a major bug in the image it might also trigger 
>> a new point release so that new users would get that fix when downloading 
>> from pharo.org ?)
>> 
> The problem is that doing a release 6.1 takes half a day of work. We could 
> improve that, but then with Pharo7 all this changed anyway, so we will not 
> improve this process.
> (and not do many releases of this kind for Pharo6).
> 
>> So a reasonably active Pharo user (but not a more bleeding edge new release 
>> user) should typically download the latest image every month to stay current?
>> 
> Normally you have a CI that builds from the latest pharo image + the latest 
> commit from your repo and you start with that all couple of days/weeks (This 
> is important
> to make sure that you have a reproduce build, too).
> 
>> We should encourage more seasoned users to also try a leading edge point 
>> release, and apply the latest hot fix image particularly in the latter part 
>> of year when we are trying to stabilise for the next release cycle. And then 
>> there are the instructions about taking the next leap for contributing back…
>> 
>> Is this right? 
> 
> Not really. *all* fixes that go into the stable release go into the 
> development release, too. So the releases of stable Pharo6 have not much todo 
> with Pharo7, no need to run a special
> Pharo6 when we stabilize Pharo7. Here it is important that people use Pharo7.
> 
> Keep in mind that we try to do active development only in the development 
> branch, so we talk about 20-30 fixes in total, many many are not really that 
> important or are just important for
> those who ran into them.
> 
> So we should not be too complex about it… it worked fine like this the last 
> 

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Marcus Denker]

> On 18 Aug 2017, at 13:08, Tim Mackinnon  wrote:
> 
> Thanks Marcus - and definitely we all appreciate that its holiday season and 
> that a lot of this is driven by community and people donating their free time.
> 
> I’m still a bit unclear on the moving parts. To paraphrase what you have said:
> 
> We start each yearly cycle with a X.0 new release. Then there may be point 
> releases 6.1, 6.2 etc where there is a breaking change (typically a new VM I 
> guess - but is there anything else that would cause a .x release?).
> 
> Then there are  “hot fixes” that causes an image number change (these have 
> worked there way through the CI, as it triggered a new build)? The 
> implication is then that what I download from Pharo.org  
> is the last point release,

No, the download is always the latest (with all accepted fixes integrated).

> but then I can go and find a newer image “hot fix” if I want some of the 
> latest more minor fixes (and I guess this then answers m .x question above - 
> as I guess that if there was a major bug in the image it might also trigger a 
> new point release so that new users would get that fix when downloading from 
> pharo.org ?)
> 
The problem is that doing a release 6.1 takes half a day of work. We could 
improve that, but then with Pharo7 all this changed anyway, so we will not 
improve this process.
(and not do many releases of this kind for Pharo6).

> So a reasonably active Pharo user (but not a more bleeding edge new release 
> user) should typically download the latest image every month to stay current?
> 
Normally you have a CI that builds from the latest pharo image + the latest 
commit from your repo and you start with that all couple of days/weeks (This is 
important
to make sure that you have a reproduce build, too).

> We should encourage more seasoned users to also try a leading edge point 
> release, and apply the latest hot fix image particularly in the latter part 
> of year when we are trying to stabilise for the next release cycle. And then 
> there are the instructions about taking the next leap for contributing back…
> 
> Is this right? 

Not really. *all* fixes that go into the stable release go into the development 
release, too. So the releases of stable Pharo6 have not much todo with Pharo7, 
no need to run a special
Pharo6 when we stabilize Pharo7. Here it is important that people use Pharo7.

Keep in mind that we try to do active development only in the development 
branch, so we talk about 20-30 fixes in total, many many are not really that 
important or are just important for
those who ran into them.

So we should not be too complex about it… it worked fine like this the last 
years.

Marcus

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Tim Mackinnon]

Thanks Marcus - and definitely we all appreciate that its holiday season and 
that a lot of this is driven by community and people donating their free time.

I’m still a bit unclear on the moving parts. To paraphrase what you have said:

We start each yearly cycle with a X.0 new release. Then there may be point 
releases 6.1, 6.2 etc where there is a breaking change (typically a new VM I 
guess - but is there anything else that would cause a .x release?).

Then there are  “hot fixes” that causes an image number change (these have 
worked there way through the CI, as it triggered a new build)? The implication 
is then that what I download from Pharo.org  is the last 
point release, but then I can go and find a newer image “hot fix” if I want 
some of the latest more minor fixes (and I guess this then answers m .x 
question above - as I guess that if there was a major bug in the image it might 
also trigger a new point release so that new users would get that fix when 
downloading from pharo.org ?)

So a reasonably active Pharo user (but not a more bleeding edge new release 
user) should typically download the latest image every month to stay current?

We should encourage more seasoned users to also try a leading edge point 
release, and apply the latest hot fix image particularly in the latter part of 
year when we are trying to stabilise for the next release cycle. And then there 
are the instructions about taking the next leap for contributing back…

Is this right? 

Tim

> On 18 Aug 2017, at 08:56, Marcus Denker  wrote:
> 
>> 
>> What I think would have been good is to list all the updates that where done 
>> between
>> releasing 6.0 and 6.1 *as part of the changelog* of 6.1 (even though they 
>> were already 
>> in the image that you got a minute before Pharo6.1 was released, as they 
>> where released as
>> hot fixes before).
>> 
> 
> The changelog of things done between releasing 6.0 and the release of 6.1:
> 
> 20262 Update Iceberg to 0.5.4
>   https://pharo.fogbugz.com/f/cases/20262
> 
> 20268 update iceberg v0.5.5
>   https://pharo.fogbugz.com/f/cases/20268
>   
> 20226 TabMorph should use stepping mechanism for animating background building
>   https://pharo.fogbugz.com/f/cases/20226
> 
> 20238 Run out of memory the image hangs without out of memory warning
>   https://pharo.fogbugz.com/f/cases/20238
>   
> 20218 Master branch (Pharo 6) needs to be safely merged into development 
> branch (Pharo 7).
>   https://pharo.fogbugz.com/f/cases/20218
>   
> 20187 Request use of block in certain methods
>   https://pharo.fogbugz.com/f/cases/20187
> 
> 20188 Request representation of integer literal without float exponent
>   https://pharo.fogbugz.com/f/cases/20188
> 
> 20182 Extra dot in literal array
>   https://pharo.fogbugz.com/f/cases/20182
> 
> 18760 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions
>   https://pharo.fogbugz.com/f/cases/18760
> 
> 20186 Request removal of extra statement separators (dot)
>   https://pharo.fogbugz.com/f/cases/20186
>   
> 20185 Request pipe after block argments
>   https://pharo.fogbugz.com/f/cases/20185
> 
> 20183 TraitDescription>>fileOutLocalMethodsInCategory:on: method temp var 
> name overlap
>   https://pharo.fogbugz.com/f/cases/20183
> 
> 20184 Request space between argument and selector in StdioStream>>next:
>   https://pharo.fogbugz.com/f/cases/20184
>   
> 20167 Regression with PNGReaderWriter in P6
>   https://pharo.fogbugz.com/f/cases/20167
> 
> 20198 inner structure access does not work on multiple architecture
>   https://pharo.fogbugz.com/f/cases/20198
>   
> 20110 AllocationTest>>#testOutOfMemorySignal not well suited to 64-bit
>   https://pharo.fogbugz.com/f/cases/20110
> 
> 20096 Add script pragma to SpaceTally>>printSpaceAnalysis
>   https://pharo.fogbugz.com/f/cases/20096
> 
> 20174 In the debug halo of a morph: clicking on "inspect morph" and "explore 
> morph" bring up the same window.
>   https://pharo.fogbugz.com/f/cases/20174
>   
> 20093 Missing source stamp makes changes hard to view
>   https://pharo.fogbugz.com/f/cases/20093
> 
> 20148 transforming deprecations should take #showWarning into account
>   https://pharo.fogbugz.com/f/cases/20148
>   
> 20146 ZnHTTPSTests>>#testGetPharoVersion started to fail
>   https://pharo.fogbugz.com/f/cases/20146
>   
> 
> 
> 

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Marcus Denker]

> 
> What I think would have been good is to list all the updates that where done 
> between
> releasing 6.0 and 6.1 *as part of the changelog* of 6.1 (even though they 
> were already 
> in the image that you got a minute before Pharo6.1 was released, as they 
> where released as
> hot fixes before).
> 

The changelog of things done between releasing 6.0 and the release of 6.1:

20262 Update Iceberg to 0.5.4
https://pharo.fogbugz.com/f/cases/20262

20268 update iceberg v0.5.5
https://pharo.fogbugz.com/f/cases/20268

20226 TabMorph should use stepping mechanism for animating background building
https://pharo.fogbugz.com/f/cases/20226

20238 Run out of memory the image hangs without out of memory warning
https://pharo.fogbugz.com/f/cases/20238

20218 Master branch (Pharo 6) needs to be safely merged into development branch 
(Pharo 7).
https://pharo.fogbugz.com/f/cases/20218

20187 Request use of block in certain methods
https://pharo.fogbugz.com/f/cases/20187

20188 Request representation of integer literal without float exponent
https://pharo.fogbugz.com/f/cases/20188

20182 Extra dot in literal array
https://pharo.fogbugz.com/f/cases/20182

18760 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions
https://pharo.fogbugz.com/f/cases/18760

20186 Request removal of extra statement separators (dot)
https://pharo.fogbugz.com/f/cases/20186

20185 Request pipe after block argments
https://pharo.fogbugz.com/f/cases/20185

20183 TraitDescription>>fileOutLocalMethodsInCategory:on: method temp var name 
overlap
https://pharo.fogbugz.com/f/cases/20183

20184 Request space between argument and selector in StdioStream>>next:
https://pharo.fogbugz.com/f/cases/20184

20167 Regression with PNGReaderWriter in P6
https://pharo.fogbugz.com/f/cases/20167

20198 inner structure access does not work on multiple architecture
https://pharo.fogbugz.com/f/cases/20198

20110 AllocationTest>>#testOutOfMemorySignal not well suited to 64-bit
https://pharo.fogbugz.com/f/cases/20110

20096 Add script pragma to SpaceTally>>printSpaceAnalysis
https://pharo.fogbugz.com/f/cases/20096

20174 In the debug halo of a morph: clicking on "inspect morph" and "explore 
morph" bring up the same window.
https://pharo.fogbugz.com/f/cases/20174

20093 Missing source stamp makes changes hard to view
https://pharo.fogbugz.com/f/cases/20093

20148 transforming deprecations should take #showWarning into account
https://pharo.fogbugz.com/f/cases/20148

20146 ZnHTTPSTests>>#testGetPharoVersion started to fail
https://pharo.fogbugz.com/f/cases/20146

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Marcus Denker]

> On 24 Jul 2017, at 15:11, Hilaire  wrote:
> 
> Thanks guys.
> 
> I hope it includes the fixes for the bugs impacting Dr. Geo.
> 

Hello,

I think there is a bit  of a confusion of how we do fixed for Pharo6.

I will explain:

-> if people find bugs, they end up on the issue tracker
-> Some of these get fixed. If a fix is ready, we will integrate it very
quickly. This means that only the update number changes, not the
main version number (these are bug fixes, they do not change APIs).

A good name for these updates is “hot fixes”.
They are announced to the dev list only with the automatic lists that are send
for each update.

We integrated already quite some into Pharo6 like that. The release was I think
around #60500, while 6.1 was done around #60510

Then there are cases that are more grave: 6.1 was done because it contains 
bigger
changes.

What I think would have been good is to list all the updates that where done 
between
releasing 6.0 and 6.1 *as part of the changelog* of 6.1 (even though they were 
already 
in the image that you got a minute before Pharo6.1 was released, as they where 
released as
hot fixes before).

Now if the image includes all fixes needed for DrGeo depends on a) has that 
issue been
fixed and b) if yes was all massaging done to have the update actually 
integrated.

(what does not help is that it is holiday time, e.g. I did not read emails and 
did *nothing*
 from end of Juli to yesterday, this does not help but was really, really 
needed).

Marcus

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[peter yoo]

congratulation !!!

2017-07-26 0:50 GMT+09:00 Esteban Lorenzano :

>
> On 25 Jul 2017, at 17:29, Hilaire  wrote:
>
> As the P6.1 change log is not complete enough I have to try out to
> discover:
>
> - fix for PNG regression is included
>
> - the Athen Wrap regression is still present :(
>
>
> is very complete. Is just that it does not has so many changes :)
> this was a version we told it was going to be made available to update
> iceberg (as we use iceberg for develop P7, we need to have recurrent
> updates even in Pharo 6). And since there was important modifications, we
> needed to change the backend library. And since we changed the backend
> library, we needed to change the vm. Finally, since we changed the VM, we
> were unable to apply this update as a “hot-fix” (what we do regularly, but
> version number does not change, just build number).
>
> So, Pharo 6.1 is exactly the same as before, but with: new iceberg, new
> vm, new backend library.
>
> cheers!
> Esteban
>
> ps: the other regressions, when fixed, can be applied as we usual apply
> backported hot-fixes.
>
>
> Le 25/07/2017 à 08:59, Hilaire a écrit :
>
> Meaning these tow ones ?
>
> http://forum.world.st/Regression-with-PNGReaderWriter-in-P6-
> td4951796.html#a4952046
>
> http://forum.world.st/WrapAthen-World-coordinate-td4951750.html#a4951966
>
>
> --
> Dr. Geohttp://drgeo.eu
>
>
>


-- 
http://lookandwalk.com  http://looknw.com | http://onionmixer.net
peter yoo(Jonghwa Yoo). ROK

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Esteban Lorenzano]

> On 25 Jul 2017, at 17:29, Hilaire  wrote:
> 
> As the P6.1 change log is not complete enough I have to try out to discover:
> 
> - fix for PNG regression is included
> 
> - the Athen Wrap regression is still present :(
> 

is very complete. Is just that it does not has so many changes :)
this was a version we told it was going to be made available to update iceberg 
(as we use iceberg for develop P7, we need to have recurrent updates even in 
Pharo 6). And since there was important modifications, we needed to change the 
backend library. And since we changed the backend library, we needed to change 
the vm. Finally, since we changed the VM, we were unable to apply this update 
as a “hot-fix” (what we do regularly, but version number does not change, just 
build number). 

So, Pharo 6.1 is exactly the same as before, but with: new iceberg, new vm, new 
backend library. 

cheers!
Esteban

ps: the other regressions, when fixed, can be applied as we usual apply 
backported hot-fixes.

> 
> Le 25/07/2017 à 08:59, Hilaire a écrit :
>> Meaning these tow ones ?
>> 
>> http://forum.world.st/Regression-with-PNGReaderWriter-in-P6-td4951796.html#a4952046
>>  
>> 
>> http://forum.world.st/WrapAthen-World-coordinate-td4951750.html#a4951966 
>> 
> -- 
> Dr. Geo
> http://drgeo.eu 

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Tim Mackinnon]

This is a great step to show we have a stable consistent base for the year 
ahead - thanks for pulling this off!

One small caveat on the 64bit angle - there are still some known outstanding 
bugs with 64bits - meaning that Fuel is known not to work (which might be for 
more specialised things - but it does mean we have to careful about how 64bits 
its advertised :

https://pharo.fogbugz.com/f/cases/20120/Fuel-is-not-64bits-ready 

https://pharo.fogbugz.com/f/cases/20119/ 

)

Tim

> On 24 Jul 2017, at 12:56, Esteban Lorenzano  wrote:
> 
> Hi, 
> 
> We are releasing Pharo 6.1. 
> Usually, between each major version we just apply bugfixes changing the build 
> number and not announcing new versions but this time is different since the 
> fixes applied required a new VM. 
> The principal reason for the new version is to update Iceberg support, 
> bringing it to macOS 64bits version. 
> 
> So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes: 
> 
> - running on macOS 64bits
> - adds cherry pick 
> - adds major improvements on performance for big repositories
> - adds pull request review plugin
> - repositories browser: group branches by remote
> - adds bitbucket and gitlab to recognised providers on metacello integration
> - uses libgit v0.25.1 as backend
> - several bugfixes
> 
> Other important change: 
> 
> - linux vm by default is now vm threaded heartbeat. 
> 
> We still miss 64bits Windows (sorry for that), but we are getting there. I 
> hope to have it running right after ESUG.
> 
> To download 6.1 version, you can go to http://pharo.org/download 
>  page, or with zeroconf: 
> 
> wget -O- get.pharo.org  | bash
> 
> Enjoy!
> Esteban

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Sven Van Caekenberghe]

Thank you, sounds like a really cool move.

> On 24 Jul 2017, at 13:56, Esteban Lorenzano  wrote:
> 
> Hi, 
> 
> We are releasing Pharo 6.1. 
> Usually, between each major version we just apply bugfixes changing the build 
> number and not announcing new versions but this time is different since the 
> fixes applied required a new VM. 
> The principal reason for the new version is to update Iceberg support, 
> bringing it to macOS 64bits version. 
> 
> So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes: 
> 
> - running on macOS 64bits
> - adds cherry pick 
> - adds major improvements on performance for big repositories
> - adds pull request review plugin
> - repositories browser: group branches by remote
> - adds bitbucket and gitlab to recognised providers on metacello integration
> - uses libgit v0.25.1 as backend
> - several bugfixes
> 
> Other important change: 
> 
> - linux vm by default is now vm threaded heartbeat. 
> 
> We still miss 64bits Windows (sorry for that), but we are getting there. I 
> hope to have it running right after ESUG.
> 
> To download 6.1 version, you can go to http://pharo.org/download page, or 
> with zeroconf: 
> 
> wget -O- get.pharo.org | bash
> 
> Enjoy!
> Esteban

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Tudor Girba]

Great job!

Doru


> On Jul 24, 2017, at 1:56 PM, Esteban Lorenzano  wrote:
> 
> Hi, 
> 
> We are releasing Pharo 6.1. 
> Usually, between each major version we just apply bugfixes changing the build 
> number and not announcing new versions but this time is different since the 
> fixes applied required a new VM. 
> The principal reason for the new version is to update Iceberg support, 
> bringing it to macOS 64bits version. 
> 
> So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes: 
> 
> - running on macOS 64bits
> - adds cherry pick 
> - adds major improvements on performance for big repositories
> - adds pull request review plugin
> - repositories browser: group branches by remote
> - adds bitbucket and gitlab to recognised providers on metacello integration
> - uses libgit v0.25.1 as backend
> - several bugfixes
> 
> Other important change: 
> 
> - linux vm by default is now vm threaded heartbeat. 
> 
> We still miss 64bits Windows (sorry for that), but we are getting there. I 
> hope to have it running right after ESUG.
> 
> To download 6.1 version, you can go to http://pharo.org/download page, or 
> with zeroconf: 
> 
> wget -O- get.pharo.org | bash
> 
> Enjoy!
> Esteban

--
www.tudorgirba.com
www.feenk.com

"To lead is not to demand things, it is to make them happen."