[Pharo-dev] PharoLauncher - uninformative Pharo7 template names

Ben Coman btc at openinworld.com
Sun Aug 6 11:46:53 EDT 2017

On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito <guillermopolito at gmail.com>

> 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 at 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
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


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...
(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 at 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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170806/a75f35e1/attachment.html>

More information about the Pharo-dev mailing list