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... > > >> >> >>> >>> >>>> 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? > True true. That's why I say it's a cache :). While this is cheap enough to have all builds stored, I'm ok with it. > > > >> >> >>> Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUIL >>>>> D_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-b >> f8112f4242808a7d70517e28088f72b >> >> >>> 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 > Ah! I understand now. You want to tag with a # the latest build. > > > cheers -ben > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13