On Mon, Aug 7, 2017 at 7:32 PM, Guillermo Polito <guillermopol...@gmail.com> wrote:
> > > On Mon, Aug 7, 2017 at 3:17 AM, Ben Coman <b...@openinworld.com> wrote: > >> >> >> 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. >> > > 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... > Yes. Which is why we need either: * the filenames on the file server to include a build number or date * PharoLauncher modified to get the date from the directory info to mix into its displayed name which is preferable? cheers -ben
