Thanks for caring.
I would vote to have the build number BEFORE the sha in the image name as this allows for easy sorting if we have several image files or image file
Archives in a single/the same folder (sort from older to more recent Images) as it is for instance on files.pharo.org
Thanks
T.
Am 06.08.2017, 09:40, Guillermo Polito <guillermopol...@gmail.com> schrieb:
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.
GuilleOn Sun, Aug 6, 2017 at 9:05 AM, Guillermo Polito <guillermopol...@gmail.com> wrote:Hi, I created an issue: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.s...@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 <asta...@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" <b...@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
Phone: +33 06 52 70 66 13
--
Guille Polito
Research Engineer
French National Center for Scientific Research - http://www.cnrs.fr
Phone: +33 06 52 70 66 13
