Next Lift version will be 2.0

[Heiko Seeberger]

Lifters,

Maybe you followed the discussion about the versioning policy for Lift. The committers finally decided to have a well defined versioning policy which you can take from here: http://wiki.github.com/dpp/liftweb/about-versioning-policy.

Following this policy the next Lift version will be 2.0, not 1.1, because there are numerous changes and enhancements breaking the source compatibility. As soon as we change the version numbers in the Maven POMs, we will let you know via the lift-announce mailing list.

Best regards,

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

[Timothy Perrett]

Heiko,

This is great - can you work with IRC to arrange a time to changes the poms to 2.0-SNAPSHOT?

Cheers, Tim

--

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.

[David Pollak]

Heiko,

Thank you for shepherding this issue through and giving us a sane and well defined naming process.

Thanks,

David

--

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.

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

[Indrajit Raychaudhuri]

Heiko,

Grand stuff!

Indeed, I was wondering if we could sync this up with the Round 2 of
Refactoring exercise
(http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df).
New structure, new version.

I am working on this refactoring in a private copy and am planning to
publish the branch once M8 is out (assuming original schedule of 2 weeks
from 27th Nov). Would this work with you?

Cheers, Indrajit

On 07/12/09 4:23 PM, Timothy Perrett wrote:
> Heiko,
>
> This is great - can you work with IRC to arrange a time to changes the
> poms to 2.0-SNAPSHOT?
>
> Cheers, Tim
>
> On 7 Dec 2009, at 08:32, Heiko Seeberger wrote:
>
>> Lifters,
>>
>> Maybe you followed the discussion about the versioning policy for
>> Lift. The committers finally decided to have a well defined versioning
>> policy which you can take from here:
>> http://wiki.github.com/dpp/liftweb/about-versioning-policy.
>>
>> Following this policy the next Lift version will be 2.0, not 1.1,
>> because there are numerous changes and enhancements breaking the
>> source compatibility. As soon as we change the version numbers in the
>> Maven POMs, we will let you know via the lift-announce mailing list.
>>
>> Best regards,
>>
>> 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

>> <mailto:lif...@googlegroups.com>.

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

>> <mailto:liftweb+u...@googlegroups.com>.

[Josh Suereth]

Heiko,

Just curious what the difference between Major and Minor truly is as both can break source/binary compatibility?   My feeling here is that sticking to strick source-compatibility for minor releases is actually a bonus. 

The other question I have is about deprecations.   What's your plan for handling these?   When can deprecated features be removed, etc.   That might feed into the source-compatibility issues in minor versions.

I think this is great stuff!  Whatever is decided here will help shape the future of the Scala community's versioning, so I hope you don't mind my pestering ;)

- Josh

[Heiko Seeberger]

2009/12/7 Josh Suereth <joshua....@gmail.com>

Just curious what the difference between Major and Minor truly is as both can break source/binary compatibility?   My feeling here is that sticking to strick source-compatibility for minor releases is actually a bonus. 

Major changes (e.g. moving/renaming an API class, changing an API method's signature, etc.) will break source compatibility for sure, i.e. for "users" and "implementers". Minor changes (e.g. adding an abstract method to an API trait) will at maximum break source compatibility for "implementers". So from a "user's" perspective minor changes add new stuff which could be used but do not break source compatibility, whereas major changes will require changing the source code.

Examples: Renaming LiftRules to LiftConfig is a major change, adding a second parameter to LiftRules.parseDate is also a major change. But adding a second method LiftRules.parseDate is only a minor change (in this case even binary compatibility should be given).

The other question I have is about deprecations.   What's your plan for handling these?   When can deprecated features be removed, etc.   That might feed into the source-compatibility issues in minor versions.

This is a good question and I do not have a plan yet ;-) As a first shot I would say that deprecated features have to survive all minor changes (must not break source compatibility for "users") and maybe one major change. The latter is the question we have to discuss ...

 

I think this is great stuff!  Whatever is decided here will help shape the future of the Scala community's versioning, so I hope you don't mind my pestering ;)

Don't worry ;-)

Heiko

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

[Heiko Seeberger]

Indrajit,

Sorry for the very late reply :-(

2009/12/7 Indrajit Raychaudhuri <indr...@gmail.com>

Grand stuff!

Thank you!

 

Indeed, I was wondering if we could sync this up with the Round 2 of
Refactoring exercise
(http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df).
New structure, new version.

Definitely yes!

 

I am working on this refactoring in a private copy and am planning to
publish the branch once M8 is out (assuming original schedule of 2 weeks
from 27th Nov). Would this work with you?

+1

Heiko

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

[Indrajit Raychaudhuri]

On 09/12/09 11:01 PM, Heiko Seeberger wrote:
> Indrajit,
>
> Sorry for the very late reply :-(
>
> 2009/12/7 Indrajit Raychaudhuri <indr...@gmail.com

> <mailto:indr...@gmail.com>>

>
> Grand stuff!
>
>
> Thank you!
>
> Indeed, I was wondering if we could sync this up with the Round 2 of
> Refactoring exercise
> (http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df).
> New structure, new version.
>
>
> Definitely yes!
>
> I am working on this refactoring in a private copy and am planning to
> publish the branch once M8 is out (assuming original schedule of 2 weeks
> from 27th Nov). Would this work with you?
>
>
> +1

Wonderful! I'll circulate an update once I publish the 'all new' 2.x
branch after M8.

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