On Nov 17, 11:38 am, Heiko Seeberger <heiko.seeber...@googlemail.com> wrote: > 2009/11/17 David Pollak <feeder.of.the.be...@gmail.com> > > > The current Lift is not a major change to Lift 1.0, it's a minor > > progression and a lot of tuning of the developer experience. > > There are breaking changes to the API which in the version policy suggested > by me (the OSGi way) means increasing the major version number. OK, of > course we need not stick to this particular version policy, but it would be > beneficial to have one. What about: Increasing the minor version number > (e.g. 1.0 -> 1.1) means breaking changes to the API. Increasing the micro > version number (e.g. 1.1.0 -> 1.1.1) means *no* breaking changes to the API.
+1 This is the standpoint that's most aligned with the de-facto policy that we have had with 1.0 series. We sure can follow this for 1.1 series too. The only addition could be to start with an actual micro version (1.1.0 instead of 1.1). The other situation where a software bumps up to next higher version is when it move to a major upstream products (and breaks backward compatibility for the better). Seeing through Lift, we can possibly state: Lift 1.1.x: on Java 5/6 and Scala 2.7/2.8 [supports 2.8.x but backward compatible with 2.7.x] Lift 2.0.x: on Java 6 and Scala 2.8 [moving away from backward compatibility with Java < 6 and Scala < 2.8.x and hence *major* backward incompatible change] - Indrajit > > Heiko > > 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=.
