PharoLauncher - uninformative Pharo7 template names
Attached is what I see for Pharo 7 images in PharoLauncher. I presume the top one is the latest, but Its a bit hard to tell :P Anyone else seeing this? Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) and doing "ConfigurationOfPharoLauncher loadDevelopment" which loads PharoLauncher-Core-ChristopheDemarey.116 (latest) This is with Pharo builds 60486 and 60510, and same VM for both... Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker versionString VM: 201705310241 CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 (but btw, does that look strange? The 60510 image was lauched from the original 60486-PharoLauncher which said it was downloading the matching VM, so I kind of expect each image to have a different VM ?? ) cheers -ben
On Fri, Aug 4, 2017 at 3:22 PM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Ben,
reason is that for Pharo 7 currently an sha git hash is used in the file name instead of a (more clear) build number.
See http://files.pharo.org/image/70/
This problem (which has more side effects on different sides, not only the Launcher now) was discussed already yesterday on Discord #iceberg channel with Esteban and Pavel.
The current sha based image file name scheme is not only confusing but has some downsides. One can not easily remember the SHA or see which image is the latest, or sort from recent images to older in a folder.
If I understood correctly the reason to (initially) choose sha's in the image name has something to do with Travis and a discussion between Pavel, Esteban and Guille.
I would vote for using Build numbers again.
We would have several BENEFITS when keeping/returning to build numbers for Pharo 7: - we do not change image file names, about box behavior, ... compared to previous Pharo version < 7 (as we used image build number already in the past) - we tag each release as before and see it in Git (we can easily reproduce) - the build number easily tells you which image is more recent (as before) - we can easily sort when we have several images in a directory - a build number is more readable and recognizable by a human (compared to the shas) - Pharo is not an "aliens" compared to the rest of the software world as often software follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) - we do not change the order in Launcher (higher numbers at the top to download more recent)
According to the discussion with Esteban and Pavel it is technically possible to have build numbers again - it means to tag each commit again with a build number (we already did this for Pharo 6, see https://github.com/pharo-project/pharo/releases)
Annotating build-commits with tags "seems" the right way to go, but I haven't played with them much. There does seem to some potential confusion in how tags operate to pay attention to... https://stackoverflow.com/questions/16678072/fetching-all-tags-from-a-remote... The example here by joshtkling that has two fetch lines might be useful (but I'm not sure if thats relevant to libgit or just to command-line git)... https://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/ cheers -ben
The outcome from yesterday was that Pavel will discuss again with Guile on that topic. It would be good if others could comment on that topic too. Maybe we can return to the known build number scheme or (if there are problems with that) at least know the arguments why we need to be exotic/different on this corner in the future.
Thanks T.
*Gesendet:* Donnerstag, 03. August 2017 um 15:41 Uhr *Von:* "Ben Coman" <btc@openinworld.com> *An:* "Pharo Development List" <pharo-dev@lists.pharo.org> *Betreff:* [Pharo-dev] PharoLauncher - uninformative Pharo7 template names
Attached is what I see for Pharo 7 images in PharoLauncher. I presume the top one is the latest, but Its a bit hard to tell :P Anyone else seeing this?
Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) and doing "ConfigurationOfPharoLauncher loadDevelopment" which loads PharoLauncher-Core-ChristopheDemarey.116 (latest)
This is with Pharo builds 60486 and 60510, and same VM for both... Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker versionString VM: 201705310241 CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017
(but btw, does that look strange? The 60510 image was lauched from the original 60486-PharoLauncher which said it was downloading the matching VM, so I kind of expect each image to have a different VM ?? )
cheers -ben
Hi torsten Yes it sounds good to have MAJOR.MINOR.PATCH/BUILDNUMBER scheme On Fri, Aug 4, 2017 at 9:22 AM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Ben,
reason is that for Pharo 7 currently an sha git hash is used in the file name instead of a (more clear) build number.
See http://files.pharo.org/image/70/
This problem (which has more side effects on different sides, not only the Launcher now) was discussed already yesterday on Discord #iceberg channel with Esteban and Pavel.
The current sha based image file name scheme is not only confusing but has some downsides. One can not easily remember the SHA or see which image is the latest, or sort from recent images to older in a folder.
If I understood correctly the reason to (initially) choose sha's in the image name has something to do with Travis and a discussion between Pavel, Esteban and Guille.
I would vote for using Build numbers again.
We would have several BENEFITS when keeping/returning to build numbers for Pharo 7: - we do not change image file names, about box behavior, ... compared to previous Pharo version < 7 (as we used image build number already in the past) - we tag each release as before and see it in Git (we can easily reproduce) - the build number easily tells you which image is more recent (as before) - we can easily sort when we have several images in a directory - a build number is more readable and recognizable by a human (compared to the shas) - Pharo is not an "aliens" compared to the rest of the software world as often software follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) - we do not change the order in Launcher (higher numbers at the top to download more recent)
According to the discussion with Esteban and Pavel it is technically possible to have build numbers again - it means to tag each commit again with a build number (we already did this for Pharo 6, see https://github.com/pharo-project/pharo/releases)
The outcome from yesterday was that Pavel will discuss again with Guile on that topic. It would be good if others could comment on that topic too. Maybe we can return to the known build number scheme or (if there are problems with that) at least know the arguments why we need to be exotic/different on this corner in the future.
Thanks T.
Gesendet: Donnerstag, 03. August 2017 um 15:41 Uhr Von: "Ben Coman" <btc@openinworld.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names
Attached is what I see for Pharo 7 images in PharoLauncher. I presume the top one is the latest, but Its a bit hard to tell :P Anyone else seeing this?
Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) and doing "ConfigurationOfPharoLauncher loadDevelopment" which loads PharoLauncher-Core-ChristopheDemarey.116 (latest)
This is with Pharo builds 60486 and 60510, and same VM for both... Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker versionString VM: 201705310241 CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017
(but btw, does that look strange? The 60510 image was lauched from the original 60486-PharoLauncher which said it was downloading the matching VM, so I kind of expect each image to have a different VM ?? )
cheers -ben
Hi, I created an issue: https://pharo.fogbugz.com/f/cases/20290/Add-build-number-to-uploaded-files I propose to keep both the sha and add the build number. Also, to follow semantic version conventions, we should use $- instead of $/. Something like: {Major}.{Minor}.{Patch}-sha.{sha}.build.{buildnumber} What do you think? I'll propose a pull request in some minutes. On Sat, Aug 5, 2017 at 6:17 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi torsten
Yes it sounds good to have MAJOR.MINOR.PATCH/BUILDNUMBER scheme
On Fri, Aug 4, 2017 at 9:22 AM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Ben,
reason is that for Pharo 7 currently an sha git hash is used in the file name instead of a (more clear) build number.
See http://files.pharo.org/image/70/
This problem (which has more side effects on different sides, not only the Launcher now) was discussed already yesterday on Discord #iceberg channel with Esteban and Pavel.
The current sha based image file name scheme is not only confusing but has some downsides. One can not easily remember the SHA or see which image is the latest, or sort from recent images to older in a folder.
If I understood correctly the reason to (initially) choose sha's in the image name has something to do with Travis and a discussion between Pavel, Esteban and Guille.
I would vote for using Build numbers again.
We would have several BENEFITS when keeping/returning to build numbers for Pharo 7: - we do not change image file names, about box behavior, ... compared to previous Pharo version < 7 (as we used image build number already in the past) - we tag each release as before and see it in Git (we can easily reproduce) - the build number easily tells you which image is more recent (as before) - we can easily sort when we have several images in a directory - a build number is more readable and recognizable by a human (compared to the shas) - Pharo is not an "aliens" compared to the rest of the software world as often software follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) - we do not change the order in Launcher (higher numbers at the top to download more recent)
According to the discussion with Esteban and Pavel it is technically possible to have build numbers again - it means to tag each commit again with a build number (we already did this for Pharo 6, see https://github.com/pharo-project/pharo/releases)
The outcome from yesterday was that Pavel will discuss again with Guile on that topic. It would be good if others could comment on that topic too. Maybe we can return to the known build number scheme or (if there are problems with that) at least know the arguments why we need to be exotic/different on this corner in the future.
Thanks T.
Gesendet: Donnerstag, 03. August 2017 um 15:41 Uhr Von: "Ben Coman" <btc@openinworld.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names
Attached is what I see for Pharo 7 images in PharoLauncher. I presume the top one is the latest, but Its a bit hard to tell :P Anyone else seeing this?
Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) and doing "ConfigurationOfPharoLauncher loadDevelopment" which loads PharoLauncher-Core-ChristopheDemarey.116 (latest)
This is with Pharo builds 60486 and 60510, and same VM for both... Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker versionString VM: 201705310241 CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017
(but btw, does that look strange? The 60510 image was lauched from the original 60486-PharoLauncher which said it was downloading the matching VM, so I kind of expect each image to have a different VM ?? )
cheers -ben
-- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
I made a PR https://github.com/pharo-project/pharo/pull/185 this PR adds a script that will rename built archives accordingly. I propose the following file names for the zip: Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUILD_NUMBER}.zip Where: IMAGE_KIND is the built product (core image, image with monticello, image with metacello, full image...) HASH is the commit hash BUILD_NUMBER is the build number set by jenkins, or "nobuildnumber" if not available Moreover, this only makes part of a "prepare for upload" script and not the main build process. That is because of simplicity right now. However, if we put the build number by default in the main archives, there may be several drawbacks: - PR's builds will have build numbers conflicting with the main builds (which may be confusing) - when building locally, we do not necessarily have a build number available so it does not make much sense Once the PR is accepted/integrated, we should change the build process to use this script. Guille On Sun, Aug 6, 2017 at 9:05 AM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi, I created an issue:
https://pharo.fogbugz.com/f/cases/20290/Add-build-number-to-uploaded-files
I propose to keep both the sha and add the build number. Also, to follow semantic version conventions, we should use $- instead of $/. Something like:
{Major}.{Minor}.{Patch}-sha.{sha}.build.{buildnumber}
What do you think? I'll propose a pull request in some minutes.
On Sat, Aug 5, 2017 at 6:17 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi torsten
Yes it sounds good to have MAJOR.MINOR.PATCH/BUILDNUMBER scheme
On Fri, Aug 4, 2017 at 9:22 AM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Ben,
reason is that for Pharo 7 currently an sha git hash is used in the file name instead of a (more clear) build number.
See http://files.pharo.org/image/70/
This problem (which has more side effects on different sides, not only the Launcher now) was discussed already yesterday on Discord #iceberg channel with Esteban and Pavel.
The current sha based image file name scheme is not only confusing but has some downsides. One can not easily remember the SHA or see which image is the latest, or sort from recent images to older in a folder.
If I understood correctly the reason to (initially) choose sha's in the image name has something to do with Travis and a discussion between Pavel, Esteban and Guille.
I would vote for using Build numbers again.
We would have several BENEFITS when keeping/returning to build numbers for Pharo 7: - we do not change image file names, about box behavior, ... compared to previous Pharo version < 7 (as we used image build number already in the past) - we tag each release as before and see it in Git (we can easily reproduce) - the build number easily tells you which image is more recent (as before) - we can easily sort when we have several images in a directory - a build number is more readable and recognizable by a human (compared to the shas) - Pharo is not an "aliens" compared to the rest of the software world as often software follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) - we do not change the order in Launcher (higher numbers at the top to download more recent)
According to the discussion with Esteban and Pavel it is technically possible to have build numbers again - it means to tag each commit again with a build number (we already did this for Pharo 6, see https://github.com/pharo-project/pharo/releases)
The outcome from yesterday was that Pavel will discuss again with Guile on that topic. It would be good if others could comment on that topic too. Maybe we can return to the known build number scheme or (if there are problems with that) at least know the arguments why we need to be exotic/different on this corner in the future.
Thanks T.
Gesendet: Donnerstag, 03. August 2017 um 15:41 Uhr Von: "Ben Coman" <btc@openinworld.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names
Attached is what I see for Pharo 7 images in PharoLauncher. I presume the top one is the latest, but Its a bit hard to tell :P Anyone else seeing this?
Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) and doing "ConfigurationOfPharoLauncher loadDevelopment" which loads PharoLauncher-Core-ChristopheDemarey.116 (latest)
This is with Pharo builds 60486 and 60510, and same VM for both... Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker versionString VM: 201705310241 CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017
(but btw, does that look strange? The 60510 image was lauched from the original 60486-PharoLauncher which said it was downloading the matching VM, so I kind of expect each image to have a different VM ?? )
cheers -ben
--
Guille Polito
Research Engineer
French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr>
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
-- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
About tagging... It looks super ackward to me to tag EVERY commit with "build information". Building does not mean releasing... I prefer the other way around: we tag builds with commit information. Like that we know how to reproduce the build. I'm ok with tagging build artifacts by explicitly saying "this is BUILD #X", which is ~= from "this is RELEASE #X". Moreover, before we needed to store ALL versions of the image because that was the way we versionned the system. Now, every commit in the #development branch should be buildable (delta some bugs of course ;)). This means that we can rebuild all images by just iterating the git history and building from scratch. No need to store all images. On Sun, Aug 6, 2017 at 9:40 AM, Guillermo Polito <guillermopolito@gmail.com> wrote:
I made a PR
https://github.com/pharo-project/pharo/pull/185
this PR adds a script that will rename built archives accordingly. I propose the following file names for the zip:
Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUILD_NUMBER}.zip
Where:
IMAGE_KIND is the built product (core image, image with monticello, image with metacello, full image...) HASH is the commit hash BUILD_NUMBER is the build number set by jenkins, or "nobuildnumber" if not available
Moreover, this only makes part of a "prepare for upload" script and not the main build process. That is because of simplicity right now. However, if we put the build number by default in the main archives, there may be several drawbacks:
- PR's builds will have build numbers conflicting with the main builds (which may be confusing) - when building locally, we do not necessarily have a build number available so it does not make much sense
Once the PR is accepted/integrated, we should change the build process to use this script.
Guille
On Sun, Aug 6, 2017 at 9:05 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Hi, I created an issue:
https://pharo.fogbugz.com/f/cases/20290/Add-build-number-to- uploaded-files
I propose to keep both the sha and add the build number. Also, to follow semantic version conventions, we should use $- instead of $/. Something like:
{Major}.{Minor}.{Patch}-sha.{sha}.build.{buildnumber}
What do you think? I'll propose a pull request in some minutes.
On Sat, Aug 5, 2017 at 6:17 PM, Stephane Ducasse <stepharo.self@gmail.com
wrote:
Hi torsten
Yes it sounds good to have MAJOR.MINOR.PATCH/BUILDNUMBER scheme
On Fri, Aug 4, 2017 at 9:22 AM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Ben,
reason is that for Pharo 7 currently an sha git hash is used in the file name instead of a (more clear) build number.
See http://files.pharo.org/image/70/
This problem (which has more side effects on different sides, not only the Launcher now) was discussed already yesterday on Discord #iceberg channel with Esteban and Pavel.
The current sha based image file name scheme is not only confusing but has some downsides. One can not easily remember the SHA or see which image is the latest, or sort from recent images to older in a folder.
If I understood correctly the reason to (initially) choose sha's in the image name has something to do with Travis and a discussion between Pavel, Esteban and Guille.
I would vote for using Build numbers again.
We would have several BENEFITS when keeping/returning to build numbers for Pharo 7: - we do not change image file names, about box behavior, ... compared to previous Pharo version < 7 (as we used image build number already in the past) - we tag each release as before and see it in Git (we can easily reproduce) - the build number easily tells you which image is more recent (as before) - we can easily sort when we have several images in a directory - a build number is more readable and recognizable by a human (compared to the shas) - Pharo is not an "aliens" compared to the rest of the software world as often software follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) - we do not change the order in Launcher (higher numbers at the top to download more recent)
According to the discussion with Esteban and Pavel it is technically possible to have build numbers again - it means to tag each commit again with a build number (we already did this for Pharo 6, see https://github.com/pharo-project/pharo/releases)
The outcome from yesterday was that Pavel will discuss again with Guile on that topic. It would be good if others could comment on that topic too. Maybe we can return to the known build number scheme or (if there are problems with that) at least know the arguments why we need to be exotic/different on this corner in the future.
Thanks T.
Gesendet: Donnerstag, 03. August 2017 um 15:41 Uhr Von: "Ben Coman" <btc@openinworld.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names
Attached is what I see for Pharo 7 images in PharoLauncher. I presume the top one is the latest, but Its a bit hard to tell :P Anyone else seeing this?
Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) and doing "ConfigurationOfPharoLauncher loadDevelopment" which loads PharoLauncher-Core-ChristopheDemarey.116 (latest)
This is with Pharo builds 60486 and 60510, and same VM for both... Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker versionString VM: 201705310241 CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017
(but btw, does that look strange? The 60510 image was lauched from the original 60486-PharoLauncher which said it was downloading the matching VM, so I kind of expect each image to have a different VM ?? )
cheers -ben
--
Guille Polito
Research Engineer
French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr>
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
--
Guille Polito
Research Engineer
French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr>
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
-- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
About tagging... It looks super ackward to me to tag EVERY commit with "build information".
I'm not sure which comment your responding to, and not sure what you mean by "build information", but obviously someone may do several commits before doing a pull request, as they work through developing and testing a fix for an Issue. Its only the successful builds that are uploaded to files.pharo.org that are important to tag.
Building does not mean releasing... I prefer the other way around: we tag builds with commit information. Like that we know how to reproduce the build.
I'm ok with tagging build artifacts by explicitly saying "this is BUILD #X", which is ~= from "this is RELEASE #X".
I'd imagine that tagging a commit as BUILD#X would be done as part of the CI immediately before the upload to files.pharo.org.
Moreover, before we needed to store ALL versions of the image because that was the way we versionned the system. Now, every commit in the #development branch should be buildable (delta some bugs of course ;)). This means that we can rebuild all images by just iterating the git history and building from scratch.
I don't understand why you'd need to iterate git history. Shouldn't you be able to rebuild an image from a single git commit?
No need to store all images.
Do you mean on files.pharo.com? That might be a good later goal, but for now these resultant images are useful to work with PharoLauncher without expending effort on redeveloping that to also rebuild images on the fly. cheers -ben
On Sun, Aug 6, 2017 at 9:40 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
I made a PR
https://github.com/pharo-project/pharo/pull/185
this PR adds a script that will rename built archives accordingly. I propose the following file names for the zip:
Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUILD_NUMBER}.zip
+1 to Torsten's suggestion to put the BUILD_NUMBER first, since it is more sortable than HASH. By "arch", do you mean Win/Linux/Mac? Or were labelling the bit-ness field? Also, is it important to prepend these with the numbers with "build." and "sha." fieldname strings? This bulks out the name increases the chance some interface needs to mangle the name to fit into a thin column. While we are discussion version naming (and I ask this from a position of ignorance) could you discuss with your team, without insider knowledge, how do we distinguish between the released 7.0.0 and all the 7.0.0 development builds heading towards that release? Can we add something to distinguish the development phase i.e. alpha/beta/rc/release (which coincidentally sort well with build numbers.) Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-alpha.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-beta.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-rc.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-release.${BUILD_NUMBER}.${HASH}.zip beta might be the defined point to ask applications to test-port to the new version, this perhaps being the optimum point to get fixes into the the next release. or if you don't want to be that sophisticated, maybe just phases dev/rel or for a more continuous release process, maybe '#' for the patch number... Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-${BUILD_NUMBER}.${HASH}.zip (since '#' sorts before '0') cheers -ben
Where:
IMAGE_KIND is the built product (core image, image with monticello, image with metacello, full image...) HASH is the commit hash BUILD_NUMBER is the build number set by jenkins, or "nobuildnumber" if not available
Moreover, this only makes part of a "prepare for upload" script and not the main build process. That is because of simplicity right now. However, if we put the build number by default in the main archives, there may be several drawbacks:
- PR's builds will have build numbers conflicting with the main builds (which may be confusing) - when building locally, we do not necessarily have a build number available so it does not make much sense
Once the PR is accepted/integrated, we should change the build process to use this script.
Guille
On Sun, Aug 6, 2017 at 9:05 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Hi, I created an issue:
https://pharo.fogbugz.com/f/cases/20290/Add-build-number-to- uploaded-files
I propose to keep both the sha and add the build number. Also, to follow semantic version conventions, we should use $- instead of $/. Something like:
{Major}.{Minor}.{Patch}-sha.{sha}.build.{buildnumber}
What do you think? I'll propose a pull request in some minutes.
On Sat, Aug 5, 2017 at 6:17 PM, Stephane Ducasse < stepharo.self@gmail.com> wrote:
Hi torsten
Yes it sounds good to have MAJOR.MINOR.PATCH/BUILDNUMBER scheme
On Fri, Aug 4, 2017 at 9:22 AM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Ben,
reason is that for Pharo 7 currently an sha git hash is used in the file name instead of a (more clear) build number.
See http://files.pharo.org/image/70/
This problem (which has more side effects on different sides, not only the Launcher now) was discussed already yesterday on Discord #iceberg channel with Esteban and Pavel.
The current sha based image file name scheme is not only confusing but has some downsides. One can not easily remember the SHA or see which image is the latest, or sort from recent images to older in a folder.
If I understood correctly the reason to (initially) choose sha's in the image name has something to do with Travis and a discussion between Pavel, Esteban and Guille.
I would vote for using Build numbers again.
We would have several BENEFITS when keeping/returning to build numbers for Pharo 7: - we do not change image file names, about box behavior, ... compared to previous Pharo version < 7 (as we used image build number already in the past) - we tag each release as before and see it in Git (we can easily reproduce) - the build number easily tells you which image is more recent (as before) - we can easily sort when we have several images in a directory - a build number is more readable and recognizable by a human (compared to the shas) - Pharo is not an "aliens" compared to the rest of the software world as often software follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) - we do not change the order in Launcher (higher numbers at the top to download more recent)
According to the discussion with Esteban and Pavel it is technically possible to have build numbers again - it means to tag each commit again with a build number (we already did this for Pharo 6, see https://github.com/pharo-project/pharo/releases)
The outcome from yesterday was that Pavel will discuss again with Guile on that topic. It would be good if others could comment on that topic too. Maybe we can return to the known build number scheme or (if there are problems with that) at least know the arguments why we need to be exotic/different on this corner in the future.
Thanks T.
On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <btc@openinworld.com> wrote:
On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
About tagging... It looks super ackward to me to tag EVERY commit with "build information".
I'm not sure which comment your responding to,
yours :P. Yes, too early, I did not want to properly quote...
and not sure what you mean by "build information",
In this particular case I mean build number. but obviously someone may do several commits before doing a pull request,
as they work through developing and testing a fix for an Issue. Its only the successful builds that are uploaded to files.pharo.org that are important to tag.
But then, why not just going through the files in files.pharo.org and get the corresponding hash from there (since they have the hash they correspond to)? I do not see the practical usecase. It's just redundance, no?
Building does not mean releasing... I prefer the other way around: we tag
builds with commit information. Like that we know how to reproduce the build.
I'm ok with tagging build artifacts by explicitly saying "this is BUILD #X", which is ~= from "this is RELEASE #X".
I'd imagine that tagging a commit as BUILD#X would be done as part of the CI immediately before the upload to files.pharo.org.
That's what I wanto to avoid. Why is that required? The generated file already has a pointer to the git commit it was generated from. Why do we need the backpointer from git to the build?
Moreover, before we needed to store ALL versions of the image because that was the way we versionned the system. Now, every commit in the #development branch should be buildable (delta some bugs of course ;)). This means that we can rebuild all images by just iterating the git history and building from scratch.
I don't understand why you'd need to iterate git history. Shouldn't you be able to rebuild an image from a single git commit?
Yes you are. I meant in here that "if you want to rebuild all images from files.pharo.org" you can walk all commits.
No need to store all images.
Do you mean on files.pharo.com? That might be a good later goal, but for now these resultant images are useful to work with PharoLauncher without expending effort on redeveloping that to also rebuild images on the fly.
Yeah, I did not mean that we have to change it. But we have to keep in mind that before files.pharo.org was used for versioning purposes but in a process where we are bootstrapping from sources, the intermediate generated images are build artifacts and are just a "cache". I know the launcher depends on it right now, but does it make sense that it provides access to every alpha image
Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUILD_NUMBER}.zip
+1 to Torsten's suggestion to put the BUILD_NUMBER first, since it is more sortable than HASH.
Ok, that's easily doable :) https://github.com/pharo-project/pharo/pull/185/files#diff-bf8112f4242808a7d...
By "arch", do you mean Win/Linux/Mac? Or were labelling the bit-ness field?
bitness. Images are portable between operating systems but not between 32&64 bit vms.
Also, is it important to prepend these with the numbers with "build." and "sha." fieldname strings? This bulks out the name increases the chance some interface needs to mangle the name to fit into a thin column.
I like that they make the metadata more explicit. Otherwise we will start having strange scripts that have magic numbers here and there. At least like this we can read the file name and identify what is each field. I prefer to pay some extra bytes in filenames... About column names in UIs.... That's a UI problem. I'd not design the filename of our build artifacts because of a UI...
While we are discussion version naming (and I ask this from a position of ignorance) could you discuss with your team, without insider knowledge, how do we distinguish between the released 7.0.0 and all the 7.0.0 development builds heading towards that release? Can we add something to distinguish the development phase i.e. alpha/beta/rc/release (which coincidentally sort well with build numbers.)
Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-alpha.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-beta.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-rc.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-release.${BUILD_NUMBER}.${HASH}.zip
beta might be the defined point to ask applications to test-port to the new version, this perhaps being the optimum point to get fixes into the the next release.
or if you don't want to be that sophisticated, maybe just phases dev/rel
I like that. The only thing is that right now what is "alpha" version is managed in the file server as "latest". That will otherwise break zeroconf scripts that depend on that. I'd say every build in development is alpha so far. At some point we will move to beta. Releases and release candidates should be managed explicitly (like there is someone that will decide "this is a release and I'll tag it explicitly like it").
or for a more continuous release process, maybe '#' for the patch number... Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-${BUILD_NUMBER}.${HASH}.zip (since '#' sorts before '0')
I did not get this one. Guille
On Mon, Aug 7, 2017 at 12:25 AM, Guillermo Polito <guillermopolito@gmail.com
wrote:
On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <btc@openinworld.com> wrote:
On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
About tagging... It looks super ackward to me to tag EVERY commit with "build information".
I'm not sure which comment your responding to,
yours :P. Yes, too early, I did not want to properly quote...
and not sure what you mean by "build information",
In this particular case I mean build number.
but obviously someone may do several commits before doing a pull request,
as they work through developing and testing a fix for an Issue. Its only the successful builds that are uploaded to files.pharo.org that are important to tag.
But then, why not just going through the files in files.pharo.org and get the corresponding hash from there (since they have the hash they correspond to)? I do not see the practical usecase. It's just redundance, no?
Building does not mean releasing... I prefer the other way around: we tag
builds with commit information. Like that we know how to reproduce the build.
I'm ok with tagging build artifacts by explicitly saying "this is BUILD #X", which is ~= from "this is RELEASE #X".
I'd imagine that tagging a commit as BUILD#X would be done as part of the CI immediately before the upload to files.pharo.org.
That's what I wanto to avoid. Why is that required? The generated file already has a pointer to the git commit it was generated from. Why do we need the backpointer from git to the build?
So should PharoLauncher attach a datestamp to each entity? There needs to be something visible that a human can sort by. I guess this is an interim solution until PharoLauncher is made to work with Iceberg, but we need something working until then.
Moreover, before we needed to store ALL versions of the image because that was the way we versionned the system. Now, every commit in the #development branch should be buildable (delta some bugs of course ;)). This means that we can rebuild all images by just iterating the git history and building from scratch.
I don't understand why you'd need to iterate git history. Shouldn't you be able to rebuild an image from a single git commit?
Yes you are. I meant in here that "if you want to rebuild all images from files.pharo.org" you can walk all commits.
got it.
No need to store all images.
Do you mean on files.pharo.com? That might be a good later goal, but for now these resultant images are useful to work with PharoLauncher without expending effort on redeveloping that to also rebuild images on the fly.
Yeah, I did not mean that we have to change it. But we have to keep in mind that before files.pharo.org was used for versioning purposes but in a process where we are bootstrapping from sources, the intermediate generated images are build artifacts and are just a "cache".
I know the launcher depends on it right now, but does it make sense that it provides access to every alpha image
It may make sense when someone wants to bisect an Issue to determine when a defect was introduced. How does the time downloading ten images compare to bootstrapping ten images?
Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUILD_NUMBER}.zip
+1 to Torsten's suggestion to put the BUILD_NUMBER first, since it is more sortable than HASH.
Ok, that's easily doable :)
https://github.com/pharo-project/pharo/pull/185/files#diff- bf8112f4242808a7d70517e28088f72b
By "arch", do you mean Win/Linux/Mac? Or were labelling the bit-ness field?
bitness. Images are portable between operating systems but not between 32&64 bit vms.
Also, is it important to prepend these with the numbers with "build." and "sha." fieldname strings? This bulks out the name increases the chance some interface needs to mangle the name to fit into a thin column.
I like that they make the metadata more explicit. Otherwise we will start having strange scripts that have magic numbers here and there. At least like this we can read the file name and identify what is each field. I prefer to pay some extra bytes in filenames...
About column names in UIs.... That's a UI problem. I'd not design the filename of our build artifacts because of a UI...
fair enough.
While we are discussion version naming (and I ask this from a position of ignorance) could you discuss with your team, without insider knowledge, how do we distinguish between the released 7.0.0 and all the 7.0.0 development builds heading towards that release? Can we add something to distinguish the development phase i.e. alpha/beta/rc/release (which coincidentally sort well with build numbers.)
Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-alpha.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-beta.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-rc.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-release.${BUILD_NUMBER}.${HASH}.zip
beta might be the defined point to ask applications to test-port to the new version, this perhaps being the optimum point to get fixes into the the next release.
or if you don't want to be that sophisticated, maybe just phases dev/rel
I like that. The only thing is that right now what is "alpha" version is managed in the file server as "latest". That will otherwise break zeroconf scripts that depend on that.
I'd say every build in development is alpha so far. At some point we will move to beta. Releases and release candidates should be managed explicitly (like there is someone that will decide "this is a release and I'll tag it explicitly like it").
or for a more continuous release process, maybe '#' for the patch number... Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-${BUILD_NUMBER}.${HASH}.zip (since '#' sorts before '0')
I did not get this one.
I was thinking something like below, but perhaps it gets too awkward after 7.0.0. Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70001.sha.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70002.sha.${HASH}.zip ... Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70639.sha.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-.build.70640.sha.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.1-.build.70641.sha.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.2-.build.70642.sha.${HASH}.zip cheers -ben
On Mon, Aug 7, 2017 at 3:17 AM, Ben Coman <btc@openinworld.com> wrote:
On Mon, Aug 7, 2017 at 12:25 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <btc@openinworld.com> wrote:
On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
About tagging... It looks super ackward to me to tag EVERY commit with "build information".
I'm not sure which comment your responding to,
yours :P. Yes, too early, I did not want to properly quote...
and not sure what you mean by "build information",
In this particular case I mean build number.
but obviously someone may do several commits before doing a pull request,
as they work through developing and testing a fix for an Issue. Its only the successful builds that are uploaded to files.pharo.org that are important to tag.
But then, why not just going through the files in files.pharo.org and get the corresponding hash from there (since they have the hash they correspond to)? I do not see the practical usecase. It's just redundance, no?
Building does not mean releasing... I prefer the other way around: we
tag builds with commit information. Like that we know how to reproduce the build.
I'm ok with tagging build artifacts by explicitly saying "this is BUILD #X", which is ~= from "this is RELEASE #X".
I'd imagine that tagging a commit as BUILD#X would be done as part of the CI immediately before the upload to files.pharo.org.
That's what I wanto to avoid. Why is that required? The generated file already has a pointer to the git commit it was generated from. Why do we need the backpointer from git to the build?
So should PharoLauncher attach a datestamp to each entity? There needs to be something visible that a human can sort by. I guess this is an interim solution until PharoLauncher is made to work with Iceberg, but we need something working until then.
But PharoLauncher does not access commits. It never did. I think it gets all information from the file server and the naming schema of files...
Moreover, before we needed to store ALL versions of the image because that was the way we versionned the system. Now, every commit in the #development branch should be buildable (delta some bugs of course ;)). This means that we can rebuild all images by just iterating the git history and building from scratch.
I don't understand why you'd need to iterate git history. Shouldn't you be able to rebuild an image from a single git commit?
Yes you are. I meant in here that "if you want to rebuild all images from files.pharo.org" you can walk all commits.
got it.
No need to store all images.
Do you mean on files.pharo.com? That might be a good later goal, but for now these resultant images are useful to work with PharoLauncher without expending effort on redeveloping that to also rebuild images on the fly.
Yeah, I did not mean that we have to change it. But we have to keep in mind that before files.pharo.org was used for versioning purposes but in a process where we are bootstrapping from sources, the intermediate generated images are build artifacts and are just a "cache".
I know the launcher depends on it right now, but does it make sense that it provides access to every alpha image
It may make sense when someone wants to bisect an Issue to determine when a defect was introduced. How does the time downloading ten images compare to bootstrapping ten images?
True true. That's why I say it's a cache :). While this is cheap enough to have all builds stored, I'm ok with it.
Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUIL
D_NUMBER}.zip
+1 to Torsten's suggestion to put the BUILD_NUMBER first, since it is more sortable than HASH.
Ok, that's easily doable :)
https://github.com/pharo-project/pharo/pull/185/files#diff-b f8112f4242808a7d70517e28088f72b
By "arch", do you mean Win/Linux/Mac? Or were labelling the bit-ness field?
bitness. Images are portable between operating systems but not between 32&64 bit vms.
Also, is it important to prepend these with the numbers with "build." and "sha." fieldname strings? This bulks out the name increases the chance some interface needs to mangle the name to fit into a thin column.
I like that they make the metadata more explicit. Otherwise we will start having strange scripts that have magic numbers here and there. At least like this we can read the file name and identify what is each field. I prefer to pay some extra bytes in filenames...
About column names in UIs.... That's a UI problem. I'd not design the filename of our build artifacts because of a UI...
fair enough.
While we are discussion version naming (and I ask this from a position of ignorance) could you discuss with your team, without insider knowledge, how do we distinguish between the released 7.0.0 and all the 7.0.0 development builds heading towards that release? Can we add something to distinguish the development phase i.e. alpha/beta/rc/release (which coincidentally sort well with build numbers.)
Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-alpha.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-beta.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-rc.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-release.${BUILD_NUMBER}.${HASH}. zip
beta might be the defined point to ask applications to test-port to the new version, this perhaps being the optimum point to get fixes into the the next release.
or if you don't want to be that sophisticated, maybe just phases dev/rel
I like that. The only thing is that right now what is "alpha" version is managed in the file server as "latest". That will otherwise break zeroconf scripts that depend on that.
I'd say every build in development is alpha so far. At some point we will move to beta. Releases and release candidates should be managed explicitly (like there is someone that will decide "this is a release and I'll tag it explicitly like it").
or for a more continuous release process, maybe '#' for the patch number... Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-${BUILD_NUMBER}.${HASH}.zip (since '#' sorts before '0')
I did not get this one.
I was thinking something like below, but perhaps it gets too awkward after 7.0.0.
Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70001.sha.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70002.sha.${HASH}.zip ... Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70639.sha.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-.build.70640.sha.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.1-.build.70641.sha.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.2-.build.70642.sha.${HASH}.zip
Ah! I understand now. You want to tag with a # the latest build.
cheers -ben
-- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
On Mon, Aug 7, 2017 at 7:32 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Mon, Aug 7, 2017 at 3:17 AM, Ben Coman <btc@openinworld.com> wrote:
On Mon, Aug 7, 2017 at 12:25 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <btc@openinworld.com> wrote:
On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
About tagging... It looks super ackward to me to tag EVERY commit with "build information".
I'm not sure which comment your responding to,
yours :P. Yes, too early, I did not want to properly quote...
and not sure what you mean by "build information",
In this particular case I mean build number.
but obviously someone may do several commits before doing a pull
request, as they work through developing and testing a fix for an Issue. Its only the successful builds that are uploaded to files.pharo.org that are important to tag.
But then, why not just going through the files in files.pharo.org and get the corresponding hash from there (since they have the hash they correspond to)? I do not see the practical usecase. It's just redundance, no?
Building does not mean releasing... I prefer the other way around: we
tag builds with commit information. Like that we know how to reproduce the build.
I'm ok with tagging build artifacts by explicitly saying "this is BUILD #X", which is ~= from "this is RELEASE #X".
I'd imagine that tagging a commit as BUILD#X would be done as part of the CI immediately before the upload to files.pharo.org.
That's what I wanto to avoid. Why is that required? The generated file already has a pointer to the git commit it was generated from. Why do we need the backpointer from git to the build?
So should PharoLauncher attach a datestamp to each entity? There needs to be something visible that a human can sort by. I guess this is an interim solution until PharoLauncher is made to work with Iceberg, but we need something working until then.
But PharoLauncher does not access commits. It never did. I think it gets all information from the file server and the naming schema of files...
Yes. Which is why we need either: * the filenames on the file server to include a build number or date * PharoLauncher modified to get the date from the directory info to mix into its displayed name which is preferable? cheers -ben
participants (5)
-
Ben Coman -
Guillermo Polito -
stephan -
Stephane Ducasse -
Torsten Bergmann