I was thinking about this earlier, if there is to be a 2.0 I would hope there was a chance to remove deprecated code. Also consider making breaking changes @dpp hasn't been in favour of making to date. Not to annoy him. As 1.X to 2.X is a big enough change that people who don't want to move can stay with a stable 1.X and those of us who are running HEAD/TRUNK whatever these new fangled git kids call it nowadays can keep racing along.
Jono. 2009/11/17 Heiko Seeberger <[email protected]> > 2009/11/17 David Pollak <[email protected]> > >> 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. > > 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 [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=. > -- 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=.
