Scala 2.10 support

[Tobias Roeser]

Hi all,

What's the plan to support and release a Scala 2.10 binary compatible version
of Adept?

I'm about to integrate Adept into SBuild (http://sbuild.tototec.de). SBuild is
a build system and based on Scala 2.10, so a fluent integration will only be
possible with a Scala 2.10 version of Adpet. You can find a scala_2_10 branch
in my Adept fork where I already migrated adept-core and adept-cli (compare:
https://github.com/lefou/adept/compare/scala_2_10). Unfortunately, there are
some source changes required. In essence, you can not build Adept for Scala
2.9 and 2.10 from the same code base, because of API changes between Akka
2.0.x and 2.1.x. But only Akka 2.1.x upwards is 2.10 compatible.

With the current situation, I'd have to setup a rather complicated build for
my Adept SBuild integration project, which includes building a patched version
of Adept. I'd be more than glad, If I could avoid that extra work and
inconvenience. Going the Scala 2.10 route in Adept should be the preferred
way IMHO.

Best regards,
Tobias

[Fredrik Ekholdt]

Yep I agree that it should be on 2.10.

Just to let you know: there is a lot of discussions going on about Adept in our end here around variance (scala 2.10 VS 2.9 is an example of variance :)
Mark H and Josh have convinced me to change the model around so that it is simpler to support it. We will post details around this on the mailing list very soon. Unfortunately, it is quite likely to believe that there will some changes on the API.
I hope it does not hurt your effort too much, but I feel pretty confident that it is better to change now, than getting stuck later.

When changing the model, I will move to 2.10 of course :)

F

[Tobias Roeser]

Hi Fredrik,

Am Donnerstag, 12. September 2013, 10:37:30 schrieb Fredrik Ekholdt:
| Yep I agree that it should be on 2.10.
|
| Just to let you know: there is a lot of discussions going on about Adept in
| our end here around variance (scala 2.10 VS 2.9 is an example of variance
| :) Mark H and Josh have convinced me to change the model around so that it
| is simpler to support it.

I assume, you are discussing those changes in a direct way (same room), or are
there other places where it can be followed, like IRC?

| We will post details around this on the mailing
| list very soon. Unfortunately, it is quite likely to believe that there
| will some changes on the API. I hope it does not hurt your effort too
| much, but I feel pretty confident that it is better to change now, than
| getting stuck later.

That's perfectly fine for me. I just wanted to know to possibly avoid work just
because I was one day to early. ;-)

Furthermore, I think it would be helpful to get feedback from a conceptually
different build system before finalizing the API. Don't be afraid of publishing
an unstable API, as long it is clear that it is unstable.

Kind regards,
Tobias

[Fredrik Ekholdt]

On Sep 12, 2013, at 11:54 AM, Tobias Roeser wrote:

> Hi Fredrik,
>
> Am Donnerstag, 12. September 2013, 10:37:30 schrieb Fredrik Ekholdt:
> | Yep I agree that it should be on 2.10.
> |
> | Just to let you know: there is a lot of discussions going on about Adept in
> | our end here around variance (scala 2.10 VS 2.9 is an example of variance
> | :) Mark H and Josh have convinced me to change the model around so that it
> | is simpler to support it.
>
> I assume, you are discussing those changes in a direct way (same room), or are
> there other places where it can be followed, like IRC?

For now, the discussion has been in a direct way. Up until now, we weren't sure about what we really were thinking and how we felt it was supposed to work so it would have been hard to follow. From now, I will make sure the discussion is lifted to the mailing list. I didn't want it to be on the mailing list, because it was too noisy.

>
> | We will post details around this on the mailing
> | list very soon. Unfortunately, it is quite likely to believe that there
> | will some changes on the API. I hope it does not hurt your effort too
> | much, but I feel pretty confident that it is better to change now, than
> | getting stuck later.
>
> That's perfectly fine for me. I just wanted to know to possibly avoid work just
> because I was one day to early. ;-)

:) hehe yep :)

>
> Furthermore, I think it would be helpful to get feedback from a conceptually
> different build system before finalizing the API. Don't be afraid of publishing
> an unstable API, as long it is clear that it is unstable.

I really, really want your feedback so I am really glad you reached out and I will do my best to make it easy for you to be successful with it :)
Could be have been more clear on the instability I guess - will take that comment with me :) The version is ALHPA-0.8 so that should give some indication, but I see your point I think:)