Hi Eric, My normal branching policy is to cherry-pick minor bug fixes into the release branch as needed. I don't normally distinguish between build fixes vs. other kinds of fixes, but I avoid cherry-picking anything that has any chance of breaking anyone.
It sounds like you'd like me to cherry-pick these build fixes into the 0.6 release? -Kenton On Sun, May 28, 2017 at 7:58 AM, Schwarz, Eric <eschw...@arri.de> wrote: > Hello Kenton, > > mhhh, I see ... what about just one branch based on the release branch > only containing build fixes? - What that be feasible? > Cap'n Proto is IMHO a very complex thing and one may really distinguish > between build and source code fixes. > Also explicit tags as they are used in the Linux kernel development (e.g. > build: ...) concerning the commit messages would make life a lot easier. > > We have got here a rather complete CI infrastructure (Windows+VS/Mac > OSX/Linux - almost any version of anything). If I hook some CI builds for > Cap'n Proto would you be interested in getting direct feedback via e-mail > concerning build breaks? > > Cheers > Eric > > Von: Kenton Varda [mailto:ken...@cloudflare.com] > Gesendet: Freitag, 26. Mai 2017 22:10 > An: Schwarz, Eric > Cc: capnproto@googlegroups.com > Betreff: Re: [capnproto] build w/ yocto > > On Fri, May 26, 2017 at 12:54 PM, Schwarz, Eric <eschw...@arri.de> wrote: > Well, there exist different branches for Yocto which bring along different > versions of tools needed to build the stuff e.g. autotools. Obviously the > versions are not compatible as it is in the case of e.g. LaTeX (always the > same behaviour for existing features). Thus, the build behaviour changes > and there might be patches necessary which may exclude each other for > different branches. Thus, having a "krogoth" and "morty" branch for the > 0.6.0 release where just those build fixes and nothing else gets pushed on > top would make life a lot easier. Only if things build smoothly and are > easy to integrate people will use it. > > If we were to extend this to every platform on which people use Cap'n > Proto, we would quickly have an unmanageable number of branches -- at least > dozens, maybe hundreds. > > I would rather have one branch that is expected to work everywhere. If > different platforms require divergent code, then we need to auto-detect > which behavior to use, rather than maintain separate branches. > > That said, you are of course welcome to maintain your own fork of Cap'n > Proto where you apply fixes as needed for your environment. > > -Kenton > ________________________________ > [http://www.arri.com/media/sign/2017_wvs_sign.jpg] < > http://www.arri.com/camera/alexa/cameras/camera_details/alexa-sxt-w/> > > Get all the latest information from www.arri.com<http://www.arri.com/>, > Facebook<https://www.facebook.com/TeamARRI>, Twitter<https://twitter.com/ > ARRIChannel>, Instagram<http://instagram.com/arri> and YouTube< > http://www.youtube.com/user/ARRIChannel>. > > Arnold & Richter Cine Technik GmbH & Co. Betriebs KG > Sitz: München - Registergericht: Amtsgericht München - > Handelsregisternummer: HRA 57918 > Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH > Sitz: München - Registergericht: Amtsgericht München - > Handelsregisternummer: HRB 54477 > Geschäftsführer: Franz Kraus; Dr. Jörg Pohlman; Stephan Schenk; Walter > Trauninger > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/capnproto.
