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.den...@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 >
