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?
>
>
>> 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-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...
>
>
> 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
