Go for it, man. I wouldn't even mind having Stripes officially declare itself to be less concerned about backwards compatibility. Maybe we can have Stripes be the one presentation framework that doesn't get bogged after 3 years...
----- Original Message ----
From: Tim Fennell <[EMAIL PROTECTED]>
To: Stripes Development List <[email protected]>
Sent: Thursday, October 5, 2006 6:50:10 AM
Subject: [Stripes-dev] Backwards Compatibility & 1.5
From: Tim Fennell <[EMAIL PROTECTED]>
To: Stripes Development List <[email protected]>
Sent: Thursday, October 5, 2006 6:50:10 AM
Subject: [Stripes-dev] Backwards Compatibility & 1.5
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
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
