On Mon, Nov 16, 2009 at 11:13 PM, Heiko Seeberger < [email protected]> wrote:
> I think version numbers are idiotic, and created by the marketing >> department, and not engineers. >> > > I strongly disagree: An appropriate version strategy is not at all about > marketing but expresses valuable information. In OSGi increasing the major > version means breaking changes in the API, increasing the minor version > means nonbreaking changes in the API and increasing the micro version means > no changes to the API but only changes of the implementation. Further these > versions are used to declare dependencies between modules (OSGi bundles) > which results in a high degree of trust that different modules work > seamlessly together. As Lift also is to support OSGi (already some support > in place) it would be beneficial to stick to this version policy. > Version numbers only guarantee that the number is different. What you call "no changes to the API, but changes to the implementation', I call "completely destroy my expectations of how this works, and therefore creates a show stopper bug for me." Which, by your logic should have been a more major number. And this entire argument proves my point. I can counter every argument you have for your scheme with real world epic fails that happened because one person version of minor, is another persons version of major. The behavior of a method, it's implementation is part of the contract I have with the library. If you change the behavior I depend on, then that's major. No matter how minor you might think the change. Moving from a hashmap to a list is a huge change, for a sufficiently large set of data for instance. I can think of several hundred other "minor" implementation changes you can make, that can have drastic consequences to the calling code. So, just because you, or some committee think that the change is "minor", I still have to thoroughly test everything that uses your library. So calling it minor doesn't do me any good. 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. Most important it's not KISS. At least Ubuntu's year.month is simple. Most importantly it tells you that you need to test your stuff to make sure it works because stuff has changed. That's what I really need to know, that and how old is my library. How old is version 2.3.1? A year? two years? 6 months? How do I know when to go looking for an updated version of the library? > I think a 2.0 needs more time with a 2.0 mindset. > > Once 2.0 is on the table there may be more redesign involved. > > > I disagree: Versions should not express a mindset but information about > (non)breaking API changes. That's all, no magic, no marketing, no mindset. > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=. > -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
