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