Call it Lift 2.0

[Heiko Seeberger]

Hi,

There has been a large amount of new stuff and also some breaking changes since Lift 1.0. As an OSGi guy I suggest we call the next version Lift 2.0, because increasing the major version number will show the world that there are breaking changes and/or cool new features. At least, this is how versions are used in OSGi land. OK, I know that Sun follows another version strategy (keeping the major version fixed to 1 forever) and the Scala folks also seem to be stick to 2.x (quite a lot people would like 2.8 to be 3.0), but IMHO this is no reason for Lift to follow the same mislead strategy. So what do you think?

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

[Naftoli Gugenheim]

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.
Or to put it differently, I think the idea to have a 2.0 should precede the list of features and the timeframe.


-------------------------------------

[Jim Barrows]

On Mon, Nov 16, 2009 at 4:01 PM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

Hi,

There has been a large amount of new stuff and also some breaking changes since Lift 1.0. As an OSGi guy I suggest we call the next version Lift 2.0, because increasing the major version number will show the world that there are breaking changes and/or cool new features. At least, this is how versions are used in OSGi land. OK, I know that Sun follows another version strategy (keeping the major version fixed to 1 forever) and the Scala folks also seem to be stick to 2.x (quite a lot people would like 2.8 to be 3.0), but IMHO this is no reason for Lift to follow the same mislead strategy. So what do you think?

I think version numbers are idiotic, and created by the marketing department, and not engineers.  You just need a build number so you can tell if you're on the right version, and that's about it.  As you point out, one mans 1.3 is another mans 2.0. 

The version number should be something like 20091231 to indicate just how old your version is.  Anything else is just madness :)
 

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

--
James A Barrows

[Naftoli Gugenheim]

Hey, you could do what Ubuntu does -- 9.10 equals 10/2009 -- the month of its release. :)

-------------------------------------

[Heiko Seeberger]

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.

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

[David Pollak]

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.

--

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[Heiko Seeberger]

2009/11/17 David Pollak <feeder.of...@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.

Heiko

[Jonathan Ferguson]

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 <heiko.s...@googlemail.com>

--

[Naftoli Gugenheim]

I agree. I would to see a 2.0 or 3.0 or something eventually with a lot of names improved. But it's up to DPP because it's his project.

-------------------------------------

> liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> .

[Indrajit Raychaudhuri]

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

[Eric Bowman]

Sun doesn't bump the version unless they break backwards compatibility,
which they have (mostly) never done since JVM 1.0. Those classfiles
still run!

Heiko Seeberger wrote:
> Hi,
>
> There has been a large amount of new stuff and also some breaking
> changes since Lift 1.0. As an OSGi guy I suggest we call the next
> version Lift 2.0, because increasing the major version number will
> show the world that there are breaking changes and/or cool new
> features. At least, this is how versions are used in OSGi land. OK, I
> know that Sun follows another version strategy (keeping the major
> version fixed to 1 forever) and the Scala folks also seem to be stick
> to 2.x (quite a lot people would like 2.8 to be 3.0), but IMHO this is
> no reason for Lift to follow the same mislead strategy. So what do you
> think?
>
> Heiko
>

> My job: weiglewilczek.com <http://weiglewilczek.com>
> My blog: heikoseeberger.name <http://heikoseeberger.name>
> Follow me: twitter.com/hseeberger <http://twitter.com/hseeberger>
> OSGi on Scala: scalamodules.org <http://scalamodules.org>

> Lift, the simply functional web framework: liftweb.net

> <http://liftweb.net>
>
> --~--~---------~--~----~------------~-------~--~----~

> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com

> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com

> For more options, visit this group at

> http://groups.google.com/group/liftweb?hl=en
> -~----------~----~----~----~------~----~------~--~---
>


--
Eric Bowman
Boboco Ltd
ebo...@boboco.ie
http://www.boboco.ie/ebowman/pubkey.pgp
+35318394189/+353872801532

[Jim Barrows]

On Mon, Nov 16, 2009 at 11:13 PM, Heiko Seeberger <heiko.s...@googlemail.com> 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 lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=.

--
James A Barrows

[David Pollak]

On Mon, Nov 16, 2009 at 11:08 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:

I agree. I would to see a 2.0 or 3.0 or something eventually with a lot of names improved.

If you want to improve names, propose it on this list.  Kris just opened up a thread on that and you've been silent.

Now is the time to improve method names.  Now is the time to suggest alternative class names.  It's not going to be wholesale breakage, but the really bad stuff can be renamed and the rest can be politely deprecated.
 

But it's up to DPP because it's his project.

Please note how I approached this conversation.  I didn't say "no."  I didn't say, "over my dead body."  I gave my perspective on how much Lift has progressed since 1.0... and I think I've got the experience with Lift to be able to say that.  I give a lot of deference to Heiko in terms of his OSGi experience.  I have my opinion, but I'm listening and being swayed.

So, yes, I have made some decisions that have gone counter to others.  Yes, I do have the final word.  But think about our conversation when you wanted to add XML for configuring menus in SiteMap.  Did I say, "no"?  I said, "It's not the way I'd do things, but add it and let's see if people adopt it."  When Marius abstracted the Servlet stuff out of Lift, he went about it in a way different than I would have, but I think his results are awesome.  There are lots of decisions about Lift that are not my personal inclination, but if they hold together then they work.  When things don't work or there's a particular corner case (e.g., Alex's changes to the type erasure issue in Req that I have 2+ years of experience with and he has none), I pull out my veto stamp.  Maybe it feels like I do this a lot, but I think that's generally because of lot of stuff happens without a lot of disagreement and it's only when I have to disagree with folks who I have a ton of respect for, there's an "energy spike" on the list and that's what people remember.

More broadly, Lift mentally hangs together pretty well.  Yes, there's room for improvement.  Yes, there are folks with more FP experience than I have who can and are lending excellent perspectives to the code base (take a look at Kris's recent additions).  But there's general coherence across the framework.

Keeping something hanging together well and keeping people who have no reason to participate except that they want to motivated is non-trivial.  Pile onto this the fact that most of the committers are probably the smartest guys in their class.  They are among the top 1% of coders in whatever company they work for.  Each of the committers is remarkable on his/her own.  So, we've got a collection of folks who are 3 standard deviations out in their field who are all opinionated and used to being right almost all the time.  I have the challenge of keeping this tremendous group of people aligned and motivated.

Now, intersect this with the current time-constraints.  I have been a nanny-less single parent for nearly the past month.  Derek is traveling with his family and Marius and Tim are busy at work.  Debby's been occupied with other gigs so I have less process help than I usually do.  I have to balance between debates, supporting the increasing number of production sites (and, yes, Naftoli, I have supported your production site... I was sitting in this line: http://www.uplifting.me/the-h1n1-vaccine-line coding fixes for your tickets to receive a "the names you chose, they're not so good" feedback from you), the Scala 2.8 port, and the flood of newbies on the list.  So, yeah, I don't spend 2+ hours a day debating... I make shorter fuse decisions.

But, the "it's DPP's ball and he'll do with it what he wants" kind of feedback bugs me at a very, very core level.
 

-------------------------------------

Jonathan Ferguson<jo...@spiralarm.com> wrote:

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.

Which particular deprecated code are you thinking.
 

Also consider making breaking
changes @dpp hasn't been in favour of making to date.

Which changes are you thinking about?
 

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.

I'm not sure we have the resources to support a 1.X and a 2.X and a 2.7.x and a 2.8.x branch.  If there are any folks who want to step up and maintain a branch (or if there's money to hire someone), it's something worth a discussion, but I don't think there's anyone I know of who could maintain a 1.X branch if we're going to get radical with a 2.X.  I think it's one branch.
 

[Heiko Seeberger]

2009/11/17 Naftoli Gugenheim <nafto...@gmail.com>

But it's up to DPP because it's his project.

Of course David kicked off Lift and he is "managing the project actively". Yet there is also a huge Lift community. Hence I do not agree calling Lift "his project". 

And even though I do not agree with every decision, I think that it is very beneficial for Lift to have a decision maker like him. Just look at the figures: There are 30+ committers and 1500+ members in this list. Ain't that successful?

Heiko

My job: weiglewilczek.com

[Jonathan Ferguson]

2009/11/18 David Pollak <feeder.of...@gmail.com>

-------------------------------------

Jonathan Ferguson<jo...@spiralarm.com> wrote:

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.

Which particular deprecated code are you thinking.

Generally, nothing concrete, there have been a few conversations on the list where you have said to leave deprecated code in place rather than remove so as not to cause undue pain.

 

 

Also consider making breaking
changes @dpp hasn't been in favour of making to date.

Which changes are you thinking about?

Once again, it was a general there have been a few conversations on the list where changing from Option to Box or renaming functions and you've suggested leaving them, once again not to cause undue pain.

 

 

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.

I'm not sure we have the resources to support a 1.X and a 2.X and a 2.7.x and a 2.8.x branch.  If there are any folks who want to step up and maintain a branch (or if there's money to hire someone), it's something worth a discussion, but I don't think there's anyone I know of who could maintain a 1.X branch if we're going to get radical with a 2.X.  I think it's one branch.

I may not have thought of this, we have 1.0.X and 1.1 at the moment. I guess I thought a 1.1 and 1.0.X would be unsupported if people didn't have money.  

[Naftoli Gugenheim]

David,
I'm really sorry if I came across badly, like if it sounded cynical or something. I did not mean it that way!
Everything you wrote about how much toil you put into this project, that's exactly my point! It's your brainchild, you started it, and you keep it going, and that's why I said is that the final decision is up to you.
I know we had a couple of disagreements about names, and as I told you then: I will be happy to debate as long as it's up for discussion; but when you make a final decision, that's your right. I'm not being bitter about it! I mean it 100%.
When someone announced they were starting a new forum for Lift, I was the one who said, let's see if DPP minds.
@Heiko: I didn't mean that it's DPP's in the sense that it's his toy, not yours and everyone else's opinion is irrelevant! I meant exactly what you responded. But it's not random that the decision maker is DPP. It's all thanks to him after all.
So I agree wholeheartedly with everything DPP and Heiko replied, and I'm sorry if I implied otherwise.
Gratitude is one of the primary distinctions between man and animal.



-------------------------------------

David Pollak<feeder.of...@gmail.com> wrote:

On Mon, Nov 16, 2009 at 11:08 PM, Naftoli Gugenheim <nafto...@gmail.com>wrote:

> I agree. I would to see a 2.0 or 3.0 or something eventually with a lot of
> names improved.


If you want to improve names, propose it on this list. Kris just opened up
a thread on that and you've been silent.

Now is the time to improve method names. Now is the time to suggest
alternative class names. It's not going to be wholesale breakage, but the
really bad stuff can be renamed and the rest can be politely deprecated.

> But it's up to DPP because it's his project.
>
>

> -------------------------------------
> Jonathan Ferguson<jo...@spiralarm.com> wrote:
>
> 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.
>

Which particular deprecated code are you thinking.

> Also consider making breaking
> changes @dpp hasn't been in favour of making to date.
>

Which changes are you thinking about?

> 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.
>

I'm not sure we have the resources to support a 1.X and a 2.X and a 2.7.x
and a 2.8.x branch. If there are any folks who want to step up and maintain
a branch (or if there's money to hire someone), it's something worth a
discussion, but I don't think there's anyone I know of who could maintain a
1.X branch if we're going to get radical with a 2.X. I think it's one
branch.


>

> Jono.
>
> 2009/11/17 Heiko Seeberger <heiko.s...@googlemail.com>
>
> > 2009/11/17 David Pollak <feeder.of...@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.
> >

> > 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 lif...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>

> <liftweb%2Bunsu...@googlegroups.com<liftweb%252Buns...@googlegroups.com>

> >
> > .
> > 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 lif...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> .
> 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 lif...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>


--

Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[David Pollak]

On Tue, Nov 17, 2009 at 2:49 PM, Jonathan Ferguson <jo...@spiralarm.com> wrote:

2009/11/18 David Pollak <feeder.of...@gmail.com>

-------------------------------------

Jonathan Ferguson<jo...@spiralarm.com> wrote:

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.

Which particular deprecated code are you thinking.

Generally, nothing concrete, there have been a few conversations on the list where you have said to leave deprecated code in place rather than remove so as not to cause undue pain.

Anything that was introduced after M5 that's now deprecated should be removed.  Anything that was deprecated in 1.0 should be removed.  The pre M5 stuff that's deprecated should be taken on a case by case basis.

If anyone would like to sign up to make a list of the above, please do and open tickets (except for the pre M5 stuff which should result in a discussion on list).
 

 

 

Also consider making breaking
changes @dpp hasn't been in favour of making to date.

Which changes are you thinking about?

Once again, it was a general there have been a few conversations on the list where changing from Option to Box or renaming functions and you've suggested leaving them, once again not to cause undue pain.

Changing return types is wicked dangerous.

There are places in the code that are currently Option[] and they should likely stay that way (stuff that's related to Scala's XML attributes deals with Option, but not Box).

I'd like to see the JSON stuff moved from Option to Box, but that's Joni's call.

If there are additional Option that should be Box, let's see what they are.

In terms of renaming stuff, Kris opened a thread on this.  Now is the time to suggest changes.

I am all for cleaning up Lift's method & class names, but where it can't be done with a simple depcrecation cycle, then we have to see the trade-offs between making the change and the value of the change.

Thanks,

David
 

 

 

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.

I'm not sure we have the resources to support a 1.X and a 2.X and a 2.7.x and a 2.8.x branch.  If there are any folks who want to step up and maintain a branch (or if there's money to hire someone), it's something worth a discussion, but I don't think there's anyone I know of who could maintain a 1.X branch if we're going to get radical with a 2.X.  I think it's one branch.

I may not have thought of this, we have 1.0.X and 1.1 at the moment. I guess I thought a 1.1 and 1.0.X would be unsupported if people didn't have money.  

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=.

[Jack Widman]

I would like to second this. What David has created here is quite incredible. Between Lift itself and the community surrounding it. This is all very impressive.

--
Jack Widman

co-founder / cto,  Authoritude, Inc.

203-641-9355

[Joni Freeman]

On 18 marras, 01:10, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> I'd like to see the JSON stuff moved from Option to Box, but that's Joni's
> call.

Hi,

I do not agree. We have quite a lot of lift-json users who do not yet
use other parts of Lift, and Box is not a familiar construct outside
of Lift. I really like to keep it that way. But could lift REST APIs
wrap the lib to provide more Liftesque API?

Cheers Joni

[Heiko Seeberger]

Jim,

2009/11/17 Jim Barrows <jim.b...@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.

 

So, just because you, or some committee ...

Not a committe, but the developer of the library.

 

... 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"?

 

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!

 

That's what I really need to know,

Please accept that other folks might have different needs.

 

[Jim Barrows]

On Wed, Nov 18, 2009 at 10:25 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

Jim,

2009/11/17 Jim Barrows <jim.b...@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

[Heiko Seeberger]

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.b...@gmail.com>

--
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 lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=.

--

[Jim Barrows]

Only if Phx is in town :)

James A Barrows

[David Pollak]

It's more of a return-type issue.

The reason I created Box in the first place is that Option doesn't give you the ability to capture reasons for None (yeah, there's Either... although there wasn't when I introduced Box [Can at the time], but you can't use Either in a for comprehension).

In reviewing the JSON code, there's actually nothing that I'd change in the APIs.  I would support Box everywhere there's support for Option (serializing/deserializing and implicit helpers).
 

Cheers Joni

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=.

[Joni Freeman]

Hi,

I will look into adding Box support.

Cheers Joni

On 19 marras, 21:24, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[Heiko Seeberger]

Folks,

I would like to bring this version discussion to an end. 

I would prefer 2.0 but, I am also cool with 1.1. If there are still unheard arguments for 2.0, please speak out now.

For me it is important that there is a version policy in place, such that everyone knows what's the difference between a change to 1.1 or to 1.0.2. As we probably will stick to Lift 1.1, IMHO the version policy has to be: "Increasing the major or minor version number means breaking changes, increasing the micro version number keeps the API stable.". Opinions?

Heiko

[Timothy Perrett]

Heiko,

Sounds pretty rational - couldn't agree more that we need a suitable policy in place.

Cheers, Tim

[David Pollak]

On Sat, Nov 21, 2009 at 4:29 AM, Timothy Perrett <tim...@getintheloop.eu> wrote:

Heiko,

Sounds pretty rational - couldn't agree more that we need a suitable policy in place.

Heiko, can you find the stated version number policies of 3 or 4 other well regarded open source projects?  That will allow us to synthesize the best of what others have done into a coherent policy for Lift.
 

Cheers, Tim

On 21 Nov 2009, at 08:27, Heiko Seeberger wrote:

> For me it is important that there is a version policy in place, such that everyone knows what's the difference between a change to 1.1 or to 1.0.2. As we probably will stick to Lift 1.1, IMHO the version policy has to be: "Increasing the major or minor version number means breaking changes, increasing the micro version number keeps the API stable.". Opinions?
>

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=.

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[Heiko Seeberger]

Hi,

Heiko, can you find the stated version number policies of 3 or 4 other well regarded open source projects?  That will allow us to synthesize the best of what others have done into a coherent policy for Lift.

Take a look at the recommended OSGi version policy: http://www.aqute.biz/Code/XBnd

Then take a look at Eclipse (pretty well known, eh?): http://wiki.eclipse.org/index.php/Version_Numbering

Both use a major increment (1.x -> 2) to show breaking changes in API, a minor increment (1.1.x -> 1.2) to show non-breaking changes in API and a micro increment to show "internal" (no class name changes, no method signature changes, ...) changes (e.g. bug fixes in the implementation).

[Josh Suereth]

I think eclipse and maven might be two of the only projects following that convention (besides others in the eclipse ecosystem).  The question in my mind is what is the popular version number convention in the Scala ecosystem.

- Josh

[Heiko Seeberger]

2009/11/21 Josh Suereth <joshua....@gmail.com>

I think eclipse and maven might be two of the only projects following that convention (besides others in the eclipse ecosystem).  

I think that Spring also follows the recommended OSGi versioning policy, but to be sure I will check with some of the Spring folks. And what about Java EE? Just remember 2.0->2.1 (small refinements and additions) and then 3.0 (very very breaking stuff).

 

The question in my mind is what is the popular version number convention in the Scala ecosystem.

As far as I can tell, e.g. from the 2.8 or 3.0 discussion on scala-internals, not many folks from Scala world are interested or trustful in versioning policies. So why not make Lift the thought leader in this regard?

Heiko

[Josh Suereth]

No argument there!  My only point was that perhaps in scala a slightly different policy might make sense.  Because certain features of scala are more backwards-compatable then others, and you are still forced to recompile your libraries/projects to all use the same scala version,  I think whatever version system you use should focus on the following aspects:

• Binary Comptability Issues
  
• Internal changes on classes or object methods, no API changes.   No need to recompile project
  
• Minor API changes (additions of methods, internal method implementation changes not belonging to traits.).  No Need to recompile project
  
• Minor Trait implementation and API changes.  Requires a recompile of anything extending from these traits.  Binary incompatable as of how traits compile today.  Source should still remain compatible.
  
• Major changes ->  similar to above, requires rebuild of project.
  
• Source Compatability Issues
  
• A project on previous version could be compiled against current version but with potential deprecation warnings
• This could even include  method signature changes if, e.g. an implicit conversion from one type of argument to the new argument is provided.  I beleive is this implicit is @deprecated, then it will issue a warning on conversion.  I know Mark Harrah uses this to acheive source-compatability across the SBT scalac plugin.
• A project on the previous version could not be compiled against this version, re-writing code is required.

My opinion on a version system for scala is as follows (unfortunately 2.8.0 breaks some of these rules...)

X -> This X version implies source-incompatible changes from previous X versions
X.Y -> The Y version implies source-compatible, but binary incompatible changes from previous X versions.
X.Y.Z -> The Z version implies internal changes such that only classes/objects extending traits need to be recompiled.
X.Y.Z.A -> The A Version implies a completely internal change such that no recompilation is necessary (I don't see these happening all that often in real life.. Traits are far to useful!).

This adds an additional layer from the normal OSGi versioning system.   My reasoning is that we hope X.Y.Z.A version numbers disappear (in favor of X.Y.Z) as research into how to compile traits for the JVM improves.

Notice as well that X.Y is only *source* compatible.   Not binary-compatible.   That's the other difference from an OSGi perspective.

The real question is, with all these breaking changes in lift 1.1, has any attempt been made at source-compatability?   If not, I would argue a bigger version jump than 1.1.

Also, there is the possibility of taking the version system and adding a "functionality milestone" version at the begginning.  In this case, you can use that number for marketting purposes (e.g. "Lift goes 1.0!).   Your version number would then be   <Marketing>.<SourceCompatability>.<All but Trait BinaryCompatability>.<Binary Compatibility>. 

In this case, perhaps a  "1.1" release makes sense vs. a "1.0" release.   The question is, should it have been 1.0.2 or 1.0.0.2?


Anyway, those are my thoughts, let me know what you think.

- Josh

[Heiko Seeberger]

Josh,

Thank you for your brilliant elaboration of compatibility issues!

2009/11/22 Josh Suereth <joshua....@gmail.com>

The real question is, with all these breaking changes in lift 1.1, has any attempt been made at source-compatability?   If not, I would argue a bigger version jump than 1.1.

The current Lift is not source compatible with 1.0.x, just consider Box moved from ...util to ...common.

Hence you would go for 2.0, right?

 

Also, there is the possibility of taking the version system and adding a "functionality milestone" version at the begginning.  In this case, you can use that number for marketting purposes (e.g. "Lift goes 1.0!).   Your version number would then be   <Marketing>.<SourceCompatability>.<All but Trait BinaryCompatability>.<Binary Compatibility>. 

I am all against using versioning policy for marketing!

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

[Timothy Perrett]

Interesting - this is something i've not actually thought about: If we were to compile a list of all the breaking changes in 1.1, perhaps that would give some focus to this discussion... as josh points out, there are most likely quite a few now and 1.0 -> 1.1 is a fairly short jump.

Loc and LocParam
Actor -> LiftActor
Full,Box etc have moved packages
JSON parsing alterations and changes in JsExp

Im probably missing a number of others, but we are talking about some fairly significant breaks here, right?

Cheers, Tim

[Josh Suereth]

The real question is could you still keep source compatibility if you made use of some interesting implict and @deprecated annotations?   I believe those are acceptable.

- Josh

[Josh Suereth]

On Mon, Nov 23, 2009 at 2:09 AM, Heiko Seeberger <seeb...@weiglewilczek.com> wrote:

Josh,

Thank you for your brilliant elaboration of compatibility issues!

[snip/]

 

Also, there is the possibility of taking the version system and adding a "functionality milestone" version at the begginning.  In this case, you can use that number for marketting purposes (e.g. "Lift goes 1.0!).   Your version number would then be   <Marketing>.<SourceCompatability>.<All but Trait BinaryCompatability>.<Binary Compatibility>. 

I am all against using versioning policy for marketing!

Ah, but this is the real world.  Providing a means for marketing to use the first version number and still letting engineering have some control seems a better world to me than what I currently have ;)

- Josh

[Timothy Perrett]

I guess this conversation should have taken place before we started doing milestone releases etc - stuff thats "broken" will have to stay "broken" now otherwise we'll be making more "breaking" changes just to un-break previous stuff... 

Cheers, Tim

[Heiko Seeberger]

Please let's not widen this discussion into something else but the question which versioning policy we are to apply. Building some kind of "compatibility layer" could be done regardless of the next Lift version number.

Do we have a consensus, that there are several substantial changes breaking source and binary compatibility? And do we have a consensus, that this is something which requires increasing the major version number?

Heiko

2009/11/23 Josh Suereth <joshua....@gmail.com>

--
Heiko Seeberger
Managing Director Technology

Besuchen Sie unser Eclipse Demo Camp am 26.11. in Stuttgart   http://wiki.eclipse.org/Eclipse_DemoCamps_November_2009/Stuttgart

Weigle Wilczek GmbH
Martinstraße 42-44
73728 Esslingen
Deutschland

T (+49) 711 46050250
F (+49) 711 45999829
www.weiglewilczek.com

Geschäftsführer / Managing Directors: Dr. Jörn Weigle, Dr. Stephan Wilczek, Heiko Seeberger
Sitz der Gesellschaft / Domicile: Esslingen a. N.
Amtsgericht / Register Court: Stuttgart, HRB 214442
USt-Ident.-Nr. / VAT ID: DE 213 472 880