Definitely go for it. Stripes should take advantage of its position as the young up-and-comer and be open to BC breaks more than more mature (read: slower moving) projects are.
Patrick Lightbody Autoriginate, Inc. 503-488-5402 http://www.autoriginate.com [EMAIL PROTECTED] "Intelligent testing made convenient" On Oct 5, 2006, at 4:50 AM, Tim Fennell wrote: > Hey All, > > I'm wondering what you all would think of some (mostly minor) > backwards compatibility breaks in Stripes 1.5? I'm not thinking of > doing anything too drastic, the two things I have in mind so far are: > > 1. Changing the default way classes are scanned for. I've found a > new way that should be more resilient in the face of bizarre > classloaders and classloader setups, and probably more efficient to > boot. It would require the specification of one or more "root" > package to start scanning from (e.g. com.myco or > com.myco.web.stripes) and then scans from there on down. The change > would *require* a new configuration property and would remove two > existing ones (ActionResolver.*Filters). Of course, a nice big error > message can be lobbed at users who still have the old configuration. > > 2. Changing @Before and @After to take an on="" attribute. This > breaks things because the lifecycle stages are currently specified as > the value attribute, which means the attribute name can be omitted > because it's the only attribute. This would cause compile breaks (at > least it'd be found early), but can be fixed with a relatively simple > search/replace for @Before(XXX) -> @Before(stages=XXX) > > My take is that if these are clearly documented in the release notes > and announcements, along with how to deal with them, it's probably > not a big deal. I'd figure that for someone who knows what they're > doing, fixing these things is probably a 15-30 minute task during the > upgrade - they don't change some fundamental way Stripes works or > alter backwards compatibility of features that will impact how most > action beans work. I also think that it's probably better to bite > the bullet and make sure Stripes 1.5 is as good and clean as > possible, instead of trying to come up with a not so great solution > that keeps backwards compatibility. > > I might also take the time to remove some of the methods that have > been deprecated since early on (like Stripes 1.1/1.2). So, what do > you all think? > > -t > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Stripes-development mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/stripes-development ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Stripes-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-development
