On Jun 4, 2014 9:37 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > > We're going on 3 weeks with a failing Mustella now, and lots of commits > still being made to the repo... > > Are you ready to revert whatever is causing these failures? You know who > you are... >
+1 to revert code that is breaking Mustella. Let's move them to a branch and make all tests pass on develop branch, please. Thanks, Om > EdB > > > > > On Mon, Jun 2, 2014 at 8:38 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > On 6/2/14 11:25 AM, "Michael A. Labriola" <labri...@digitalprimates.net> > > wrote: > > > > >>Makes sense and we probably should have done that in the first place. > > >>But since we didn't, do we change behavior and risk breaking folks or > > >>add a flag and keep both code paths? > > > > > >The problem I have with two code paths is how do we choose between them? > > >Are we going to do a version number check or make someone compile > > >differently, etc.? Also, FWIW as a data point, other than a test which > > >was expecting a specific error to be thrown, I am going to highly doubt > > >anyone would even know a change was made unless they were working around > > >it before. Willing to go either direction but I am always hesitant to be > > >dragged down by complete backward compatibility, especially for low risk > > >items. > > Well, if you want to take the risk, go with the single code path and > > comment out the mustella tests and if it breaks someone I will point them > > to you. I won't veto such a change. > > > > If it were me, I'd add the flag, default to new behavior, and set the flag > > in the mustella tests. > > > > I agree we don't need to be completely backward compatible for past > > incorrect behavior, but I'm often reminded of how we think we won't break > > anybody and then do. > > > > -Alex > > > > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl
