On Mon, Aug 7, 2017 at 12:25 AM, Guillermo Polito <[email protected] > wrote:
> > On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <[email protected]> wrote: > >> On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito < >> [email protected]> 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
