On 2013-06-07, at 20:03, [email protected] wrote: > Marcus Denker wrote: >> Hi, >> >> I changed all links to point to the latest 2.0 build on files.pharo.org >> >> Reason: >> >> -> We are fixing bugs, yet people downloading 2.0 do not see the fix >> -> We had multiple times that people wasted quite some effort >> re-reporting bugs >> that are already fixed. >> >> Notes >> -> the file name "latest.zip" is not good for the image. It should >> encode that it is the image only and the version number maybe? >> -> I did not change any VM related download links, but I think we >> should do the same there. >> >> >> Marcus >> > That is great that 2.0 is continuing to improve. > > +100 for including version numbers on the web page - something like [1]. For > the purpose of reproducibility and least surprise, at [2] where it currently > says "2.0 (release)" and "Pharo2.0 (win)" I would expect that link to > download the _exact_ same file every time, except today that zip file > contains files dated today, so obviously is not the same file as last week. > You might get away with following "latest" with a link called "Pharo2 (win)" > without the minor-version number, but by including a a minor-version number I > would expect that it is the constant point-in-time snapshot of the _2.0 > release_. > [1] http://www.python.org/download/ > [2] http://www.pharo-project.org/pharo-download > > Also, revisiting (major.minor.bugfix) semantic versioning in the context of > Pharo, an important part of configuration management for a user is matching > versions of VM to Image. For me, I simply this when I update by always > taking the fat zip which include both - but it would be nice to have the > confidence to just take the image. So it would be good if the VM/Image > dependency could be encoded by the version numbers. Something like the > following... > > My shallow understanding of the CI infrastructure is that to "some degree" : > 1. the Image CI runs against a constant VM version
the image is tested against the latest stable vm (ex. http://files.pharo.org/vm/pahro/linux/stable.zip) since stable VMs are promoted manually we can consider them being constant. > 2. the VM CI runs against a constant Image version true, https://ci.inria.fr/pharo/view/VM/job/PharoVM-tests/ shows that we run against the latest image (2.0 in this case) and a fixed image (vm-test.zip in this case). Currently the CI infrastructure is suffering from a network failure, that's why the more runs than usual are red. > So considering Case 1... > a. Image updates would bump only the bugfix number. b. VM updates would bump > the minor number. > This would make is easy for a user to always determine that Image version > 2.2.x was tested against VM Pharo22.exe. > To avoid excessively incrementing the minor version number, considering Case > 2... > c. (for example) you would begin testing VM updates against constant Image > 2.0.0 > d. when a required VM update breaks a test in Image 2.0.0, then increment the > minor version number. Work to get latest VM and latest Image both green. > These then become Pharo21.exe and Image 2.1.0, which are used as a the next > starting point for Case 1. Further VM updates are now tested against > constant Image 2.1.0. this scheme will work fine once we release VM's for each Pharo release (which I guess is planned at some point). Currently this is not yet the case, so the objective is to make the VM work with every image...
