August 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

by Guillermo Polito

On Fri, Aug 18, 2017 at 3:40 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > first: thanks you Guille for answering my questions and providing more > documentation > on your wiki. > > Guille also cared yesterday on addressing the build number problem: > https://github.com/pharo-project/pharo/pull/212 > > Big thanks! > > Meanwhile I wrote a small "contribution" tool which I can have as an > in-image utility > that will help me (and maybe others too) with some necessary steps. > > It's a customized help topic together with some code using an external > "git" command (because using the command line is tedious) > > Maybe some of you may want to try it. To load you need: > > > Gofer it > smalltalkhubUser: 'TorstenBergmann' project: 'Contribution'; > package: 'Contribution-Tool'; > load. > > and then > > #CTPHelpTopic asClass open > > It should explain some of the steps necessary to contribute similar to > Guilles > wiki page but right from the image. It works best when you have the > "WebBrowser" > package loaded from catalog before as then the links really open a > webbrowser. > > Attached is a screenshot. > > There is also an additional tool ("CPTCloneTool run") inside of this > package to > > - clone the #development branch from your custom fork of the pharo project > into a subdirectory "contribute/pharo-gitusername" of your image > directory > > - set ttps://github.com/pharo-project/pharo.git automatically as > "upstream" remote > > - it also adds this local directory to the Iceberg "pharo" repo and > enables > the setting to show the system repositories > > - and finally opens Iceberg browser > Pavel was a week ago or so publishing a script over here that did the same. And I thought it would be good to make it an iceberg plugin. Maybe this too :) > > For simplicity it for now uses system: calls with the git command. > > So if you use this tool in a clean and fresh image it should bring you > to the point where you can start coding your change and then create a > branch for the bug number using Iceberg. > > Use it at your own risk: > ======================= > For me it works on Ubuntu, I was able to contribute with this. Have not > tried on Mac. > Unfortunately this still crashes the VM on Windows due to a new Iceberg > issue (https://github.com/pharo-vcs/iceberg/issues/438) that need to be > fixed. > > The repo on STHub is open - so if you want to extend it feel free to do so. > > Thx > T. > > Tx! -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 18, 2017

Re: [Pharo-dev] Add JSONSchemas to NeoJSON

by Sven Van Caekenberghe

Henry, You wrote directly to me: > I wish to use JSON for type encoding between different language environments, currently Squeak and Java. Unfortunately I cannot load the software in Pharo, at this time. I brought NeoJSON over into my package to work locally, and I made some changes. As you can see below, I want to use ASN1 Module style mapping registrations as well as formal schema consumption. I also wish to use Fuel style substitutions. However, I realize NeoJSON may already have a substitution mechanism. > > The issue with substitutions while walking a graph of objects, and this is what Fuel solves (though I looked at an earlier version and do not know how it does so now) is that the graph needs to connect with proxies, then resolved into substitutions, so it is three steps: proxy-connect, substitutions, real-graph-connect. > > The reason I am reaching out, and seeing that this is August you may be on vacation, is to feel your thoughts out about using JSON Schemas. One issue I not is that the types get hardcoded and applied to data that has no $ref in the data. This makes creation of a #anyOf, #allOf, #oneOf difficult as I am unclear how discrimination occurs. > > I would love to hear your thoughts - I am 95% decided on using JSON. As you probably know, JSON is rather special in its simplicity. The original author refused to add certain elements to its specification, because he knew they would complicate matters too much. Nor does he support any of the large number of extensions that others propose(d). NeoJSON is in the first place a clean/modern implementation of a JSON parser/generator for this specification, specific for Pharo. NeoJSON tries to be as resource (time/space) efficient as possible. Because converting between domain objects and JSON is a frequent requirement, a simple mapping mechanism was added. It avoids intermediate representations. Since JSON is inherently untyped, it is not a very elegant mechanism. Especially in the area of collection/relations, the options are rather limited. Still, I think it has proven useful for many people. Refer to the documentation and unit tests to see what is available. I known very well that many schemes exist, none of these are supported as such. My answer to these feature requests is STON: it has a clean/general/elegant typing mechanism and support for cycles and structure sharing. I prefer to keep JSON very simple. It would certainly be interesting if others would write extensions to NeoJSON, similar to the ideas that you have. As long as it is a clean extension I would be totally OK with that, if necessary I will support small, compatible changes to NeoJSON itself to help you in your implementation efforts. Regards, Sven > On 13 Aug 2017, at 21:04, henry <henry(a)callistohouse.club> wrote: > > Thank you, Stef. I sent to him email, conditioned on his enjoying his vacations. > > - HH > > >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] Add JSONSchemas to NeoJSON >> Local Time: August 13, 2017 2:53 PM >> UTC Time: August 13, 2017 6:53 PM >> From: stepharo.self(a)gmail.com >> To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> Hi henry >> >> Here is the email of sven Van Caekenberghe <sven(a)stfx.eu> >> >> He is probably on vacation else he would have replied. >> This is great if you can extend neoJSON it is a nice and important >> piece of software. >> >> Stef >> >> On Sat, Aug 12, 2017 at 10:04 PM, henry <henry(a)callistohouse.club> wrote: >> > Is Sven still working on NeoJSON? I want to help expand it to use >> > JSONSchemas. >> > >> > https://spacetelescope.github.io/understanding-json-schema/ >> > >> > I was looking at ASN1Module in Cryptography... >> > >> > - HH >

Aug. 18, 2017

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

by 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/ <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(a)inria.fr> wrote: > > >> On 18 Aug 2017, at 13:08, Tim Mackinnon <tim(a)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 >

Aug. 18, 2017

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

by Torsten Bergmann

Hi, first: thanks you Guille for answering my questions and providing more documentation on your wiki. Guille also cared yesterday on addressing the build number problem: https://github.com/pharo-project/pharo/pull/212 Big thanks! Meanwhile I wrote a small "contribution" tool which I can have as an in-image utility that will help me (and maybe others too) with some necessary steps. It's a customized help topic together with some code using an external "git" command (because using the command line is tedious) Maybe some of you may want to try it. To load you need: Gofer it smalltalkhubUser: 'TorstenBergmann' project: 'Contribution'; package: 'Contribution-Tool'; load. and then #CTPHelpTopic asClass open It should explain some of the steps necessary to contribute similar to Guilles wiki page but right from the image. It works best when you have the "WebBrowser" package loaded from catalog before as then the links really open a webbrowser. Attached is a screenshot. There is also an additional tool ("CPTCloneTool run") inside of this package to - clone the #development branch from your custom fork of the pharo project into a subdirectory "contribute/pharo-gitusername" of your image directory - set ttps://github.com/pharo-project/pharo.git automatically as "upstream" remote - it also adds this local directory to the Iceberg "pharo" repo and enables the setting to show the system repositories - and finally opens Iceberg browser For simplicity it for now uses system: calls with the git command. So if you use this tool in a clean and fresh image it should bring you to the point where you can start coding your change and then create a branch for the bug number using Iceberg. Use it at your own risk: ======================= For me it works on Ubuntu, I was able to contribute with this. Have not tried on Mac. Unfortunately this still crashes the VM on Windows due to a new Iceberg issue (https://github.com/pharo-vcs/iceberg/issues/438) that need to be fixed. The repo on STHub is open - so if you want to extend it feel free to do so. Thx T.

Aug. 18, 2017

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

by Marcus Denker

> On 18 Aug 2017, at 13:08, Tim Mackinnon <tim(a)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

Aug. 18, 2017

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

by 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 <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(a)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 > > > >

Aug. 18, 2017

Latest Debian, Ubuntu and CentOS packages of the pharo-vm

by Holger Freyther

Hi, when running Pharo in production you might want to install the image and a VM from distribution packages. So far there were no current public packages and during the last months I have modernized the debian packaging and recently added CentOS rpm packaging as well. The process of generating new source packages is integrated into the pharo-vm travis-ci build as well. Every time that master of pharo-vm.git is updated a new source package will be uploaded to the Open(SUSE) Build Service and new packages will be built and are available in a "latest" package feed. The generated (and used) sourcecode is inside the source package and will be archived by the OBS platform (one can even nicely diff versions). The "stable" VM is not built from pharo-vm.git (yet?) so it doesn't show on OBS yet. Below are some semi-tested installation notes in case you want to try it out. The binary names are picked to allow to install the 32bit and 64bit VM in parallel. The names currently are: - pharo6-32 (32bit version) - pharo6-64 (64bit version) - pharo6-32-ui (32bit version with X11 dependencies) - pharo6-64-ui (64bit version with X11 dependencies) CentOS 6.8: # Add the repo $ yum-config-manager --add-repo http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/C… # Install 32bit packages (with X11 dependency for *-ui or not) $ yum install pharo6-32-ui.i686 or pharo6-32.i386 # Install 64bit packages $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64 CentOS 7 (only 64bit): $ yum-config-manager --add-repo http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/C… $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64 Debian 8: # Add signing key $ wget -O - http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/D… | apt-key add - # Update and install $ apt update $ apt install pharo6-32-ui pharo6-64-ui (or pharo6-32 or pharo6-64) Ubuntu 14.04 LTS # Add signing key $ wget -O - http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/x… | apt-key add - # Update and install $ apt update $ apt install pharo6-32-ui pharo6-64-ui Ubuntu 16.04 # Add signing key $ wget -O - http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/x… | apt-key add - # Update and install $ apt update $ apt install pharo6-32-ui pharo6-64-ui

Aug. 18, 2017

Re: [Pharo-dev] Lowering the pain of newbies

by Denis Kudriashov

Hi I wrote proposal in issue 2017-08-18 0:52 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > Is this a goal we can all share for 7.0? > > Sort out the expert tools (like git etc), but equally enable that > simplicity you expect for a child/newbie/expert... > > I'm in! > > Tim > > Sent from my iPhone > > > On 17 Aug 2017, at 20:52, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > Hi guys > > > > my son coded in Pharo 60 > > > > testGuessUrlPart > > > > |dg8| > > dg8 := GameItem new; > > name: 'Dragon Quest VIII : Journey Of The Cursed King'; > > console: 'PS2'. > > self assert: dg8 guessUrlPart equals: > > 'dragonquestviiijourneyofthecursedking' > > > > and guess what he broke the system. > > > > We should not accept such kind of behavior. > > name: should not change the name of the class. > > > > I do not know the solution but I fear when I will teach 160 students > this fall. > > We should make sure that Pharo is not a system only for experts! > > > > any idea is welcome > > > > https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT- > automatically-rename-and-destroy-the-class > > > > Stef > > > > >

Aug. 18, 2017

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

by 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

Aug. 18, 2017

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

by Marcus Denker

> On 24 Jul 2017, at 15:11, Hilaire <hilaire(a)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

Aug. 18, 2017