Backwards compatibility is really important for patches etc, but I would like to set a line in the sand (even far out), where we give people a ton of headway, and then we allow ourselves to make big structural changes that break patch compatibility.
Big ones: - Clean up formatting in files - Change the test structure - Change the source structure (going to happen with mavenization anyway, I assume). I'm sure there are other things like that. We could say "in 1 year, this will happen" or whatever, and for a couple months we could rebase patches against both to make it easier or something. 2012/3/27 Daniel Dai <[email protected]> > I'd like to but it's a huge project. We need to figure out what each > test is doing and put them in the right package. We need to > split/merge lots of test, also there are many tests cross packages, we > need to figure a way to deal with it. > > Daniel > > On Tue, Mar 27, 2012 at 11:33 AM, Bill Graham <[email protected]> > wrote: > > Hi, > > > > Is there a good reason why almost all pig tests live in > org.apache.pig.test > > and not in the package of the class they're testing? This approach means > > that many methods need to be made public just for testing instead of > > package private. It also makes it harder to find tests in a package with > > 212 classes in it. > > > > What would people feel about changing this standard to put test classes > in > > the package name of the class you're testing? It would be great to move > > classes to new packages, but then there's that whole breaking patches > > part... > > > > thanks, > > Bill >
