Jim, Let's stop this discussion (I won't convince you and you wont't convince me) and start doing something more valuable: Are you in town for a couple of beers?
Heiko 2009/11/18 Jim Barrows <jim.barr...@gmail.com> > > > On Wed, Nov 18, 2009 at 10:25 AM, Heiko Seeberger < > heiko.seeber...@googlemail.com> wrote: > >> Jim, >> >> 2009/11/17 Jim Barrows <jim.barr...@gmail.com> >> >>> >>> The behavior of a method, it's implementation is part of the contract I >>> have with the library. >>> >> >> Behavior yes, as long as agreed part of the contract. Implementation no. >> > > Implementation is not behavior? > > >> >> >>> So, just because you, or some committee ... >>> >> >> Not a committe, but the developer of the library. >> > > I don't care who. Somebody, who isn't me, is deciding whether the impact > to me is is minor (ie 0.0.1), major (ie 0.1.0), or catastrophic (ie 1.0.0). > > >> >>> ... think that the change is "minor", I still have to thoroughly test >>> everything that uses your library. >>> >> >> Did you hear me saying "Don't test your app when a required library >> changes its version"? >> > > Yes, actually your attempting to use a scheme to tell me what I need to > test. If you agree that with every change, I need to test those changes, > then why complicate everybody's lives with number schemes? Because whether > a someone uses the OSGI complex scheme of numbers, or Ubuntus year.month > scheme, it still means I have to read the change list, and test the things > that changed. > > >> >> >>> As to your "As Lift also is to support OSGi (already some support in >>> place) it would be beneficial to stick to this version policy" comment. I >>> counter with "Lift works on Ubuntu it would be beneficial to stick to this >>> version policy" and of course "Lift runs on scala it would be beneficial to >>> stick to this version policy", or better yet "Lift runs on the Java VM it >>> would be beneficial to stick to this version policy." All three of my >>> arguments have far more to do with Lift running then OSGI does. >>> >> >> If you are not interested in OSGi or Lift's OSGi support, then just ignore >> it. As far as I know neither Ubuntu, nor Scala, nor the JVM care about >> Lift's version number or version strategy. But OSGi does! >> > > You miss my point. My point was that the argument you make is useless. > > >> >> >>> That's what I really need to know, >>> >> >> Please accept that other folks might have different needs. >> > > You cut the context. However.... Everyone needs to know that things > changed. And they need to know what changed. The OSGI scheme attempts to > tell the developer how severe the change is, without knowing how the > developer is using the library. That's useless. > -- > James A Barrows > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=. > -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
