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
2. the VM CI runs against a constant Image version
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.
Now if you do the same with Pharo 3, then of course you might end up
with Pharo25.exe and Pharo31.exe VMs being identical files, but from a
user perspective that is a reasonable price to pay for the gain in
configuration management.
P.S. Its great that the CI infrastructure even allows me to think along
these lines.
cheers -ben
