On Mon, Aug 7, 2017 at 12:25 AM, Guillermo Polito <guillermopol...@gmail.com
> wrote:

>
> On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <b...@openinworld.com> wrote:
>
>> On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito <
>> guillermopol...@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

Reply via email to