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