On Sat, Jun 19, 2010 at 3:56 AM, David Carver <[email protected]> wrote:
> Just some thoughts on this thread. > > 1. Any 1.4 or 1.3.x release should always be API compatible. So we should > never break public API here. > > 2. I would prefer that any schema changes and any serialization of classes > also remain binary compatible. Again, avoids migration and upgrade issues. > > 3. I'm all for maintenance releases being every couple of months, but I > also think it is good to plan for a 1.4 release in either 6 months or a > year. Maintenance releases should occur at least 3 or 4 times a year, minor > version releases a little bit longer out. > A bit different view on here, for 6 months or one year time frame release, I would think it should be like from 1.x to 2.x. ;-) > > 4. If we plan to do this, it would be nice to have some Milestone releases > periodically before getting to the Release canidates or maintenance > releases. Allows for testing purposes. > > 5. Ideally I'd like to see one Build system choosen as the Master build. > I know we have adopters that use buildr and some that use maven, but > maintaining two build systems isn't productive long term. > +100 here. ;), with two build system here, it is harder to make a commit, esp in big feature, as that requires you make sure both build tools work fine... For average developer, I tend to vote to use maven only, but here we have to wait for maven build is working fine, like fix all of issues that we had right now. > > 6. During the maintenance of code and any 1.4 release, ideally I'd like to > see one unit test framework settled upon. Since the majority is junit, I > think it would be a good idea as we fix other bugs and features to slowly > migrate all the tests to junit 4 style. Makes it easier to get started and > test regardless of ide or if you are running tests via the build scripts. > +1. Regards Jeff > > That's all I can think of at the moment. > > Dave > > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
