[Pharo-dev] [ANN] Pharo 6.1 (summer) released!
eliot.miranda at gmail.com
Fri Aug 18 10:58:07 EDT 2017
> On Aug 18, 2017, at 4:08 AM, Tim Mackinnon <tim at 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?
>>> On 18 Aug 2017, at 08:56, Marcus Denker <marcus.denker at 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
>> 20268 update iceberg v0.5.5
>> 20226 TabMorph should use stepping mechanism for animating background building
>> 20238 Run out of memory the image hangs without out of memory warning
>> 20218 Master branch (Pharo 6) needs to be safely merged into development branch (Pharo 7).
>> 20187 Request use of block in certain methods
>> 20188 Request representation of integer literal without float exponent
>> 20182 Extra dot in literal array
>> 18760 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions
>> 20186 Request removal of extra statement separators (dot)
>> 20185 Request pipe after block argments
>> 20183 TraitDescription>>fileOutLocalMethodsInCategory:on: method temp var name overlap
>> 20184 Request space between argument and selector in StdioStream>>next:
>> 20167 Regression with PNGReaderWriter in P6
>> 20198 inner structure access does not work on multiple architecture
>> 20110 AllocationTest>>#testOutOfMemorySignal not well suited to 64-bit
>> 20096 Add script pragma to SpaceTally>>printSpaceAnalysis
>> 20174 In the debug halo of a morph: clicking on "inspect morph" and "explore morph" bring up the same window.
>> 20093 Missing source stamp makes changes hard to view
>> 20148 transforming deprecations should take #showWarning into account
>> 20146 ZnHTTPSTests>>#testGetPharoVersion started to fail
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev