Compatibility policy

[Lars Hupel]

Now that scalaz 7.0.0 has been out for a while, I'd like to sketch some
plans for the future. Obviously, the following plans are not set in stone.

As most people probably have already read, the point-releases will stay
*binary compatible*. That is, you can use code compiled against 7.0.0
with 7.0.1 [0], same goes for 7.1.x, which will be the next major
release series.

Upgrading from 7.y to 7.y+1 will break binary compatibility. Care will
be taken to ensure source compatibility though, with a few exceptions:

* deprecated methods and classes will be removed after one major
release, i.e. deprecated in 7.y → removed in 7.y+1

* small changes or changes which affect only a few users, e.g. #325 [1]

* changes without a clear migration strategy, e.g. the undergoing effort
to remove remaining variance annotations, cannot undergo a deprecation cycle

Also, if you just migrated to 7.0.0, you don't have to go to 7.1.0
immediately after it's out :) Development effort will still continue for
a while.

If you'd like some things to be more strict, please do tell us!


[0] 7.0.1 hasn't been released yet. You can track its progress there:
<https://github.com/scalaz/scalaz/issues/323>

[1] <https://github.com/scalaz/scalaz/pull/325>

[Stefan Höck]

On 05/18/2013 09:58 PM, Lars Hupel wrote:
> * changes without a clear migration strategy, e.g. the undergoing effort
> to remove remaining variance annotations, cannot undergo a deprecation cycle

Hi Lars

Can you elaborate on this i.e. where (for which type constructors) to
you plan to remove variance annotations and why? Discussions about
variance annotations have come up again and again and I thought that
scalaz 7 would follow a strategy of variance annotations as often as
possible?

Cheers, Stefan

[Lars Hupel]

> Can you elaborate on this i.e. where (for which type constructors) to
> you plan to remove variance annotations and why? Discussions about
> variance annotations have come up again and again and I thought that
> scalaz 7 would follow a strategy of variance annotations as often as
> possible?

They have been introduced on type classes (`Monad`, ...), but it was
decided to be a bad idea, hence they got removed again a while ago. What
remains is a thorough cleanup, like in [#328] (the discussion there also
offers some insight about the motivation).

Data types (`Validation`, ...) will keep their variance annotations, but
transformers will probably not. Everything else will stay as it is.

[#328] <https://github.com/scalaz/scalaz/pull/328>

[Stephen Compall]

(Sorry for dupes, again)

On Sat, 2013-05-18 at 21:58 +0200, Lars Hupel wrote:
> Upgrading from 7.y to 7.y+1 will break binary compatibility. Care will
> be taken to ensure source compatibility though, with a few exceptions:

I would like also to be able to introduce new methods in scalaz types &
syntax here, & types e.g. OnePlus for that matter.

--
Stephen Compall
"^aCollection allSatisfy: [:each | aCondition]": less is better than

[Stephen Compall]

Lars Hupel <hu...@in.tum.de> wrote:

>Upgrading from 7.y to 7.y+1 will break binary compatibility. Care will
>be taken to ensure source compatibility though, with a few exceptions:

I would like also to be able to introduce new methods in scalaz types & syntax here, & types e.g. OnePlus for that matter.

--
Stephen Compall

If anyone in the MSA is online, you should watch this flythrough.