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
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
On Mon, Nov 23, 2009 at 6:05 AM, Timothy Perrett timo...@getintheloop.euwrote:
Interesting - this is something i've
On Mon, Nov 23, 2009 at 2:09 AM, Heiko Seeberger
seeber...@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.
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
On 23 Nov 2009, at 16:18, Josh Suereth wrote:
2009/11/21 Josh Suereth joshua.suer...@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
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
Heiko,
Sounds pretty rational - couldn't agree more that we need a suitable policy in
place.
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
On Sat, Nov 21, 2009 at 4:29 AM, Timothy Perrett timo...@getintheloop.euwrote:
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
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:
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
On Sat, Nov 21, 2009 at 9:59 AM, Heiko Seeberger
Hi,
I will look into adding Box support.
Cheers Joni
On 19 marras, 21:24, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Tue, Nov 17, 2009 at 10:06 PM, Joni Freeman freeman.j...@gmail.comwrote:
On 18 marras, 01:10, David Pollak feeder.of.the.be...@gmail.com
wrote:
I'd like to see
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
On Tue, Nov 17, 2009 at 10:06 PM, Joni Freeman freeman.j...@gmail.comwrote:
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
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.
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
Only if Phx is in town :)
On Wed, Nov 18, 2009 at 10:48 AM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
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
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
On Mon, Nov 16, 2009 at 11:13 PM, Heiko Seeberger
heiko.seeber...@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
On Mon, Nov 16, 2009 at 11:08 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
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
2009/11/17 Naftoli Gugenheim naftoli...@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
2009/11/18 David Pollak feeder.of.the.be...@gmail.com
-
Jonathan Fergusonj...@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
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
On Tue, Nov 17, 2009 at 2:49 PM, Jonathan Ferguson j...@spiralarm.comwrote:
2009/11/18 David Pollak feeder.of.the.be...@gmail.com
-
Jonathan Fergusonj...@spiralarm.com wrote:
I was thinking about this earlier, if there is to be a 2.0 I would hope
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.
On Tue, Nov 17, 2009 at 6:10 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
David,
I'm really sorry if I came across badly, like if
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
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.
-
Heiko
On Mon, Nov 16, 2009 at 4:01 PM, Heiko Seeberger
heiko.seeber...@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
Hey, you could do what Ubuntu does -- 9.10 equals 10/2009 -- the month of its
release. :)
-
Jim Barrowsjim.barr...@gmail.com wrote:
On Mon, Nov 16, 2009 at 4:01 PM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
Hi,
There has been a large amount
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,
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.
On Mon, Nov 16, 2009 at 10:13 PM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
I think version numbers are idiotic, and created by the marketing
department,
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
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
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.
-
Jonathan Fergusonj...@spiralarm.com wrote:
I was thinking about this earlier, if there is to be a 2.0 I would hope
there
33 matches
Mail list logo
