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 :( Le 25/07/2017 à 08:59, Hilaire a écrit :

Meaning these tow ones ?

http://forum.world.st/Regression-with-PNGReaderWriter-in-P6-td4951796.html#a...

http://forum.world.st/WrapAthen-World-coordinate-td4951750.html#a4951966

-- Dr. Geo http://drgeo.eu

Hi, It is the other minor bugs fixes details which were missing. What is hot-fixes? Hilaire -- Dr. Geo http://drgeo.eu

2017-07-26 16:25 GMT+02:00 Stephane Ducasse <stepharo.self@gmail.com>:

I imagine that hot-fixes means when we found a serious bug in the alpha version and see that it is also in the previous version.

Now Hilaire if you want a change to be integrated in Pharo and Pharo 60 for example.

- we should have a bug entry on fogbugz (you see when I read the emails I do not see the bug entry so I have to look for it and lose time - because crawling the bug database is tedious, so this is a lot more efficient to send also bug entries). - we should have a fix. - it should be tagged for Pharo 60. - it should be validated (pass the tests).

Each time we introduce a fix, we may break sometimes so we pay really attention to have limited fixes with limited impact.

For the ones you mentioned:

- I cannot find the PNGReader bug entry. I read all the mails of the thread. So this is not efficient.

- https://pharo.fogbugz.com/f/cases/20166/ is there but there is no fix so we will have

The problem with fixes for Athens is, that nobody could tell we what the current state is. http://forum.world.st/current-athens-configuration-td4914441.html#a4914488 the latest changes are from alexej and I guess they are important for sparta and the further development for bloc/sparte for pharo 7/8 We can not just take the latest version and put it in pharo 6, and hope that it will work. We need for this external package a good communication about changes and versions. This did not happen here. And I am not sure if we maybe already put some changes in pharo 6, that are not at the athens repository. I once considered athens as an important package for the new pharo ui, but the way it is handled now looks more like abandoned. that is the reason why I just put the fix for 20166 in the comment of the bug entry instead of providing a slice / or update the version on the repository. It is ok if we tell hilaire to not just put bugreports on the ml but create a bug report on fogbugz instead. So people can fix/provide a slice and run the validation. But this happend in this case. It is just that we do not get it right to handle this case because it depens on athens.

People are nice and trying to help now everybody has its own agenda and we set these "rules" to avoid that we all lose time. If you want that people help you then try to adhere to such best practices.

Follow the Pharo process.

Stef.

On Tue, Jul 25, 2017 at 6:01 PM, Hilaire <hilaire@drgeo.eu> wrote:

...

Hi,

It is the other minor bugs fixes details which were missing.

What is hot-fixes?

Hilaire

-- Dr. Geo http://drgeo.eu

Thanks Nicolai Hilaire Le 26/07/2017 à 17:07, Nicolai Hess a écrit :

whatever, put a slice for this case into the inbox SLICE-Issue-20166-wrong-cliprect-on-transformed-athens-canvas-NicolaiHess.1

-- Dr. Geo http://drgeo.eu

Hi, Athens is part of Pharo and the priority is to make it work for Pharo. If there are other users of such a core technology, they should be the ones adapting. @Alex Syrel: could you please take a look at the latest commits from Athens and clarify their state? Cheers, Doru

On Jul 26, 2017, at 9:44 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

Hi Nicolai

Athens is important for us too. Now none of us in the team has the experience in Cairo. Users of Athens usually do not want to invest understanding it either.

I tried to create the conditions that Igor could stay in the communautee but it failed because alone I could not do it.

Now Athens is what is in Pharo. I have no idea of the rest.

Stef

On Wed, Jul 26, 2017 at 4:42 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:

...

2017-07-26 16:25 GMT+02:00 Stephane Ducasse <stepharo.self@gmail.com>:

...

I imagine that hot-fixes means when we found a serious bug in the alpha version and see that it is also in the previous version.

Now Hilaire if you want a change to be integrated in Pharo and Pharo 60 for example.

- we should have a bug entry on fogbugz (you see when I read the emails I do not see the bug entry so I have to look for it and lose time - because crawling the bug database is tedious, so this is a lot more efficient to send also bug entries). - we should have a fix. - it should be tagged for Pharo 60. - it should be validated (pass the tests).

Each time we introduce a fix, we may break sometimes so we pay really attention to have limited fixes with limited impact.

For the ones you mentioned:

- I cannot find the PNGReader bug entry. I read all the mails of the thread. So this is not efficient.

- https://pharo.fogbugz.com/f/cases/20166/ is there but there is no fix so we will have

The problem with fixes for Athens is, that nobody could tell we what the current state is.

http://forum.world.st/current-athens-configuration-td4914441.html#a4914488

the latest changes are from alexej and I guess they are important for sparta and the further development for bloc/sparte for pharo 7/8 We can not just take the latest version and put it in pharo 6, and hope that it will work. We need for this external package a good communication about changes and versions. This did not happen here. And I am not sure if we maybe already put some changes in pharo 6, that are not at the athens repository. I once considered athens as an important package for the new pharo ui, but the way it is handled now looks more like abandoned.

that is the reason why I just put the fix for 20166 in the comment of the bug entry instead of providing a slice / or update the version on the repository.

It is ok if we tell hilaire to not just put bugreports on the ml but create a bug report on fogbugz instead. So people can fix/provide a slice and run the validation. But this happend in this case. It is just that we do not get it right to handle this case because it depens on athens.

...

People are nice and trying to help now everybody has its own agenda and we set these "rules" to avoid that we all lose time. If you want that people help you then try to adhere to such best practices.

Follow the Pharo process.

Stef.

On Tue, Jul 25, 2017 at 6:01 PM, Hilaire <hilaire@drgeo.eu> wrote:

...

Hi,

It is the other minor bugs fixes details which were missing.

What is hot-fixes?

Hilaire

-- Dr. Geo http://drgeo.eu

-- www.tudorgirba.com www.feenk.com “Live like you mean it."

If you read carefully what I wrote, I was wondering what were these small bugs fixes... and if P6.1 would be helpful for the drgeo problems: a list of bugs with links to the bug tracker will have been enough. Hilaire Le 26/07/2017 à 16:25, Stephane Ducasse a écrit :

People are nice and trying to help now everybody has its own agenda and we set these "rules"

-- Dr. Geo http://drgeo.eu

On 24 Jul 2017, at 15:11, Hilaire <hilaire@drgeo.eu> 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

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 <http://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 <http://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 <marcus.denker@inria.fr> 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

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/ <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 <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 <http://pharo.org/> and then find the image number that corresponded to that release at http://files.pharo.org/image/60/ <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/ <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 <marcus.denker@inria.fr> wrote:

...

On 18 Aug 2017, at 13:08, Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>> 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 <http://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 <http://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

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 <marcus.denker@inria.fr> wrote:

On 18 Aug 2017, at 15:41, Tim Mackinnon <tim@testit.works> 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 <http://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

Hi Tim,

On Aug 18, 2017, at 4:08 AM, Tim Mackinnon <tim@testit.works> 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?).

Ignoring plugins, since VMs are backward compatible, new VMs are never breaking changes. A new vm may have a bug in it, but that would be superseded with a fixed vm asap, the previous good vm being used until that time. But we never release a new vm that won't run old image, except in a major release cycle, and even then not every release cycle. The VM is much like a real processor which always runs code in its instruction set but new instructions get added from time to time. The change from Squeak/Pharo 4.x to 5.x was a major change (Spur memory manager). But now we're back in the regime of backward compatibility in which the 6.x VMs will happily run 5.x images. But indeed this simple story might be violated by important plugins.

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 <marcus.denker@inria.fr> 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

On 29 Jul 2017, at 10:07, Volkert <volkert@nivoba.de> wrote:

Cool. How do i figure out, if i have installed 6.1? The Welcome Page shows 6.0?

i used ... wget -O- get.pharo.org/stable+vm | bash Ubuntu 16.10 LG,

Volkert

yes, you have 6.1 believe it or not, the cost of doing a “proper release” (changing all numbers. etc.) is too big to do it frequently. That’s why we do not do this more often (also this is one of the many reasons why we are changing our process: with PR system + bootstrap, produce correct version numbers will be a lot easier). Esteban

On 24.07.2017 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 <http://pharo.org/download> page, or with zeroconf:

wget -O- get.pharo.org <http://get.pharo.org/> | bash

Enjoy! Esteban

One of my students was confused also. Envoyé de mon iPhone

Le 29 juil. 2017 à 09:50, Volkert <volkert@nivoba.de> a écrit :

...

On 29.07.2017 10:39, Esteban Lorenzano wrote:

...

On 29 Jul 2017, at 10:07, Volkert <volkert@nivoba.de> wrote:

Cool. How do i figure out, if i have installed 6.1? The Welcome Page shows 6.0?

i used ... wget -O- get.pharo.org/stable+vm | bash Ubuntu 16.10 LG,

Volkert

yes, you have 6.1 believe it or not, the cost of doing a “proper release” (changing all numbers. etc.) is too big to do it frequently. That’s why we do not do this more often (also this is one of the many reasons why we are changing our process: with PR system + bootstrap, produce correct version numbers will be a lot easier).

Esteban

better I believe you. ;-) but it is really confusing to talk about Pharo 6.1 and finding no information / notes with the release.

Volkert

On 29 Jul 2017, at 10:50, Volkert <volkert@nivoba.de> wrote:

On 29.07.2017 10:39, Esteban Lorenzano wrote:

...

...

On 29 Jul 2017, at 10:07, Volkert <volkert@nivoba.de <mailto:volkert@nivoba.de>> wrote:

Cool. How do i figure out, if i have installed 6.1? The Welcome Page shows 6.0?

i used ... wget -O- get.pharo.org/stable+vm <http://get.pharo.org/stable+vm> | bash Ubuntu 16.10 LG,

Volkert

yes, you have 6.1 believe it or not, the cost of doing a “proper release” (changing all numbers. etc.) is too big to do it frequently. That’s why we do not do this more often (also this is one of the many reasons why we are changing our process: with PR system + bootstrap, produce correct version numbers will be a lot easier).

Esteban

better I believe you. ;-) but it is really confusing to talk about Pharo 6.1 and finding no information / notes with the release.

thing is: it was just a release to include iceberg 0.5 with 64bits support. people expects a lot of changes to be listed, but this is the only real change :) Esteban

Volkert