Discuss: versioning scheme #3

Closed
ktoso opened this Issue Aug 23, 2016 · 52 comments

Projects

None yet
@ktoso
Member
ktoso commented Aug 23, 2016

As discussed in akka/akka-meta#27

A new Versioning scheme for Akka HTTP

Binary compatibility is very important to us. We’ve shown one of the best track records in the Scala ecosystem on maintaining such compatibility–including efforts that we spent between 2.3.x and 2.4.x that made these binary compatible, which would have–under the previous versioning scheme–been major releases.

Please note that Akka, since the release of 2.4.0 maintains a MAJOR.MINOR.PATCH versioning, as opposed to the previously used EPOCH.MAJOR.MINOR which used to be Scala versioning scheme inspired.

We can not use the 1.0 version to demarcate this new start as it would be very confusing since that number was already used back in July 2015 while we were working on Akka Streams & HTTP under a separate version scheme than Akka "core", which was at 2.3.x and later on continued to become 2.4.x.

Our goal with the HTTP versioning scheme is to signify that while Akka HTTP may need to bump its major version number, e.g. from 10 to 11, it would be still compatible with Akka 2.x–the stable core which will only break compatibility when a huge change is needed.

Action: After careful consideration of all of the above constraints, we propose that the new versioning scheme be different enough not be confused with Akka "core" versions. Specifically, we think using a version number much higher than 2 or 3 (which would be confusable with Akka versions) is the way to go, and suggest to start at 10.0, simultaneously announcing Akka HTTP to be stable (removing the experimental flag).

To decide: Given troublesome situation of the Directives trait being extended by user code, binary compatibility is impossible to maintain when a new directive is added into it. This will change with Scala 2.12, however with 2.11 it still is the case. We propose to keep source compatibility in minor releases, e.g. a new directive can be added but to a new trait that one mixes-in explicitly, and in a major release we can merge those new traits to the existing Directives structure. A major release may then still happen sooner than an Akka 3.0 (which is very far out), and the project can keep a healthy speed - to be determined by the team.

Please comment!

@ktoso ktoso modified the milestone: FIRST_STABLE_RELEASE Aug 23, 2016
@jypma
Contributor
jypma commented Aug 23, 2016

I actually expect there would be fairly strong dependency of akka-http on a (minimal) minor version of akka, and it may be nice for the version numbers to reflect that. So how about:

(option 2A)
2.4.9-1, i.e. (akka version it minimally depends on DASH release number). Disadvantage would be that we can't have any breaking changes in akka-http for the same akka version. Advantage is that version numbers are reckognizable but still fairly short.

(option 2B)
1.0-2.4.9, i.e. (semantic version number DASH akka version it minimally depends on). Disadvantage is longer version numbers, but we have full freedom to do minor releases, plus being able to target multiple akka versions if required.

@guidomedina
guidomedina commented Aug 25, 2016 edited

If you take into account other Akka projects, they all match the same version as Akka, the disadvantage of that is that rolling up a version might release nothing new for a particular product, but it is easier from other perspectives like 1 version number for all, people might get confused if akka-streams and akka-http-core are both at 2.4.9 and akka-http at 1.0

Take as example other projects like Jackson, even if they release nothing new for say:
jackson-annotations, they still roll a new version for the sake of consistency.

I'm not saying that doing things like the rest of the world does is necessarily a good thing but sometimes is worth to look outside to get a different perspective.

Edit: "I'm not saying"

@patriknw
Member

Here we want akka-http to be able to move faster, also for the major number, so it will not be able to keep it in sync with akka core. 1.0-2.4.9 (option 2B) is an interesting alternative to 10.0.

@guidomedina
guidomedina commented Aug 25, 2016 edited

The only problem I see (which might not be a problem at all) is that 1.0-2.4.9 if you release 2.4.10 it will look ugly, you will have Akka 2.4.10 (as an example) but still akka-http-1.0-2.4.9

if you have to coordinate to release all components in a single release cycle then the 1.0- prefix will only be there as that, as prefix but won't really have a meaning other than adding one more number.

@guidomedina
guidomedina commented Aug 25, 2016 edited

Maybe 1.0-2.4.x? or eliminate the x like indicating that it is designed for 2.4.x

Edit: It would render something like 1.0-2.4 or 1.0-2.5

@jypma
Contributor
jypma commented Aug 25, 2016

@guidomedina The 2.4.9 is supposed to indicate sth like "built against, and requires at least". Of course that'd be in the ivy dependencies as well. If we drop the .9, we'd have to say "should always work with the latest 2.4 akka" instead. Either could work.

@ktoso ktoso changed the title from Discuss versioning scheme to Discuss: versioning scheme Aug 26, 2016
@ktoso ktoso removed the 1 - triaged label Aug 26, 2016
@2m
Contributor
2m commented Aug 30, 2016

I would like to raise a concern regarding the proposed non standard version format (e.g. 1.0-2.4.9). This can potentiality trip some tools in the Scala ecosystem: Scaladex version parser, sbt dependency eviction algorithm, etc.

As @jypma mentioned above, this information is already encoded in the pom/ivy deps. So it can be parsed from there and then presented for users of various tools or websites.

I quite like the idea of a new name and then starting from 1.0.

@2m
Contributor
2m commented Aug 30, 2016

What is more, akka-http artifact id namespace is still not used. We could go with that one and start numbering from 1.0. Then the problem is with akka-http-core which has been flying under that name since 2.4.2-RC1. We could solve that by renaming just the core project to, e.g. akka-http-stream.

So then we would have, after the move and after the first release these two artifacts:

  • akka-http 1.0 (directives)
  • akka-http-stream 1.0 (http implementation as a stream for others, like playframework to build on top)
@ktoso
Member
ktoso commented Aug 30, 2016 edited

Renaming core won't fly - I see no gain from doing so, only breaking people.

I am strongly against akka-http 1.0 - it makes no sense, it already exists, we can't put people into the confusing situation of 1.0 being completely different from another 1.0 of the same project.
It will be hell in explaining what it means and we'll catch up with 2 and 3 and it will be super confusing then that it is not 1:1 with Akka main.

A new name for akka-http is something we can consider though. Would be nice to dive into this idea a bit.
It could be akka-http-directives for example.
Esp. if we would like to perhaps add akka-http-client once the high level client exists etc.

@patriknw
Member

@2m good point about the tooling, let's not go there

@ktoso ktoso referenced this issue Sep 5, 2016
Closed

Initial codebase move to this repo #13

7 of 12 tasks complete
@ktoso ktoso added the 1 - triaged label Sep 8, 2016
@jrudolph
Member
jrudolph commented Sep 13, 2016 edited

So far, I think renaming the akka-http module (akka-http-directives is somewhat clunky but also quite accurate) and starting from 1.0 sounds good for me.

It might be more tricky for akka-http-core, though. If we want to signify (binary) compatibility with older versions of akka-http-core we need to keep the same name and versioning scheme, so that ivy/maven will choose the latest one. I wonder how the release process would look like? Will we have different release cycles for akka-http-core and akka-http (and other modules)? What will the relation be between akka-http-core version numbers and other akka modules' version numbers?

@ktoso
Member
ktoso commented Sep 13, 2016 edited

So far, I think renaming the akka-http module (akka-http-directives is somewhat clunky but also quite accurate) and starting from 1.0 sounds good for me.

The rename sounds good then, let's go ahead with it. akka-http => akka-http-directives
So it seems we do not want to rename, since we can't take 1.0 anyway. That sounds good.

Starting from 1.0 is not an option, for many reasons which I explained above:

We can not use the 1.0 version to demarcate this new start as it would be very confusing since that number was already used back in July 2015 while we were working on Akka Streams & HTTP under a separate version scheme than Akka "core", which was at 2.3.x and later on continued to become 2.4.x.

  • 1.0 would cause confusion when googling / talking, since 1.0 already exists and is ancient
    • the argument that "oh but it did have experimental back then" does not solve this problem, still causes a ton of confusion
  • we can not make akka-http-core suddenly be 1.0, as it would lose version precedence and 2.4.10 would always win with it.

It might be more tricky for akka-http-core, though. If we want to signify (binary) compatibility with older versions of akka-http-core we need to keep the same name and versioning scheme, so that ivy/maven will choose the latest one.

That's not a problem. Akka 2.3 and 2.4, under old versioning scheme should not have been binary compatible, yet we made them so and documented and told people they are. Same here, we can document and explain that akka-http-core 2.4.x is binary compatible with "akka-http" 10.0, or whichever version we decide for here.

I wonder how the release process would look like?

What specifically do you have in mind? "How often", "who decides" or the technical side?

For the first part it'd be good to attempt to have regular minor releases, in Akka we do that every 3 weeks. But here we could call it more often or less often - depends on @akka/akka-http-team as well.

Will we have different release cycles for akka-http-core and akka-http (and other modules)?

No, http-core moves together with akka-http, otherwise it'll become too messy.

What will the relation be between akka-http-core version numbers and other akka modules' version numbers?

No relation I guess... We'll have to document compat and requirements well.
Akka HTTP 10.2.5 requires at least Akka 3.2.1 etc, we can make this a startup check and it'd explain that.

@jrudolph
Member

Ok, so to summarize:

  • we want only one version number for all akka-http-* modules
  • the release process is separate from akka/akka
  • version numbers should not be confusable with akka version numbers
  • we need to keep module and name of akka-http-core and it needs a version number > 2.4.x (to make sure dependency management will make newer but still compatible akka-http-core version override the old ones)

So, if there's a hard constraint of choosing a strange new version number, maybe let's just do this and not also choose a new name. (I somehow got the impression that choosing a new name was a consequence of wanting to start with 1.0 for akka-http).

@jrudolph
Member

Thanks for the explanation, @ktoso.

No, http-core moves together with akka-http, otherwise it'll become too messy.

Understood. I guess it was my main misconception before that akka-http-core was to be somehow bound to akka/akka.

No relation I guess... We'll have to document compat and requirements well.
Akka HTTP 10.2.5 requires at least Akka 3.2.1 etc, we can make this a startup check and it'd explain that.

Yes, ok, we also don't need to figure out issues that may come with the next major Akka version right now.

@ktoso
Member
ktoso commented Sep 13, 2016 edited

That summary is correct.
It would be nice to find a way without weird version number, but avoiding confusion is the prime directive here. We don't want to confuse with 2.4 Akka, nor Akka 3, and 1.0 we can't use because historical reason. So we need to move versions forward.

I'll just throw out a proposal out there then: Any objections to using 10.0.0?

Now what's left to debate is what compatibility guarantees we want to provide.
Just the usual major/minor/patch?

We can attempt keeping core "even more" compatible, but people would have to check that in our docs if 11 core is compatible with 12 etc. By default it means we jus broke compat.

Someone suggested to care about source compat, but I'm not sure that's really helping, since people are building libraries which depend on directives and make their own collections of directives out of them.

So:

10.0.0 with usual semantic versioning.

Yay / nay @akka/akka-http-team ?
Unless violent disagreement AND a better proposal is found, we'll go with that.
Estimated initial, stable, release I'd say can happen in around 3 weeks.

@ktoso ktoso added 3 - in progress and removed 1 - triaged labels Sep 13, 2016
@guidomedina
guidomedina commented Sep 13, 2016 edited

Maybe this idea has been explored before but let me say it otherwise it will be lost to the void:

What if you keep part of the versioning number with akka version, say the first 2 numbers, like akka-http-whatever-2.4.x where x is a high number, say, 10 or 20 or 100, whichever that satisfies the fact that current akka version will never catch up with that.

I know why you prefer version 10, but I find that also a bit ugly and loose, it doesn't say anything, and at least with the prefix number people will know what akka major version is required, with some exceptions, like min akka version being 2.4.2+ or something.

@ktoso
Member
ktoso commented Sep 13, 2016

Interesting idea and thanks for chiming in.
I don't think it solves a real problem though, and it specifically does not solve a real problem: being able to know when akka-http breaks compatibility, which will be more often than Akka (maybe 6 months, maybe 1 year, but more often).

Akka 3 is a huge step, and the only thing we can see that will likely cause that large jump is making Typed "the" thing or something of similar magnitude. Otherwise we're able to add a lot of stuff without breaking compatibility - all of Artery is compatible, as will be other things we're planning to work on.

@guidomedina

I know what you are saying, but a version number will never state all that it implies, for example, loose version 10 doesn't say anything, you will always have to go to the release notes to figure what akka version it requires.

Another problem, what says that version 10.0.x runs with akka 2.4.x and version 11.0.x with akka 3.0.x? some problems the user will definitely have to go to the release notes, like minor facts that version 3.0.25 requires akka 3.0.3+ for example.

It is impossible because of binary compatibility reasons to state everything in a version number, but at least the prefix states enough information, I tend not to focus on exceptions as at the end of the day they are that; exceptions, and should be treated likewise.

I think that the only difference between 10.0.x compared to 2.4.x and 11.0.x compared to 3.0.x is the fact that keeping the first two numbers (prefix) states something, not a hard written in a stone constraint, the other problem, what if you decide to release 2.5.x after 3.0.x? what happens with your scheme then?

But all this is only a matter of perception, one or the other could be the right way to go.

@guidomedina

In the other hand, a loose number makes sense because akka-http is not akka itself so it shouldn't be related, or should it? if you are trying to completely separate them then 10.0.x is the way to go, and now I'm contradicting my own idea but that's the thing, it should be looked at it as a perspective.

@jrudolph
Member

IMO if we choose 10 as next version number it will be much more confusing than if we'd choose 3.0.

It has only been for half a year that akka-http tracked akka's version numbers. Now going back to an independent numbering is a departure from that but it is not worse than what happened before. I don't think anyone will confuse this with Akka's version number because as @ktoso said Akka 3.0 will be a big step that is likely years away. Until then no one can even remember the brief period of time where akka-http's version numbers tracked akka's.

So, putting that concern aside, choosing everything else than 3 is confusing because it is so arbitrary and unusual. On the other side, 3.0 is the consequential successor to anything 2.x signifying that something major has changed in the project (which in this case would be the split out of the repository and the independent release process).

I agree that @guidomedina points are valid. An example about what happens otherwise would be the somewhat complicated compatibility situation we had in spray where you had to look it up in the documentation which version to choose based on your Akka version (based on our decision to support a wide range of Akka versions). But I don't think this argument still applies to the current situation. Akka is not moving so fast as to break things so often as it was a few years ago. Only few libraries support several major versions of their dependencies and it is the common case that aside from a period of transition a project only supports one version of its dependencies.

About which timeframe are we talking for which we expect that akka-http needs to support multiple akka versions? Do we really want to figure this out right now?

@guidomedina

About which timeframe are we talking for which we expect that akka-http needs to support multiple akka versions? Do we really want to figure this out right now?

Since it is at experimental before going stable it is the best time to try to imagine what can happen with specific scenarios, if later these things happen then it will be too late where changing won't be an option.

@ktoso
Member
ktoso commented Sep 13, 2016 edited

I'll attempt to summarise the available options.

  • 1.0, we can't use it, it has been used for akka-http already already and would be too confusing
  • 2.0 we can't, same reason as 1.0
  • 3.0 technically possible. It is the logical "something big happened" version number and would step forward from Akka 2.4.x.
    • Problem is that people may eventually find Akka 3 once it's out, and use it with Akka HTTP 3, but that would be wrong, they'd likely should use Akka HTTP 5.0 or something with Akka 3 then.
  • 10.0 would be a large significant marker that it's different from Akka "main". It marks that this version number is independent from Akka "main".
    • Downside is that it really is a bit weird
  • 10.0.0-THIS-WORKS-WITH-AKKA-2.4.9-OR-HIGHER-SEE-DOCS-FOR-DETAILS (just a joke)

Furthermore, other things:

Changing artifact group name to com.lightbend.akka (from com.typesafe.akka) during the HTTP move:

  • we can not change the artifact name, as we'd risk users of downstream libraries ending up with a mix of akka classes (say some lib included 2.4.2, and another 10.x) it'd blowup. We could claim it's not our fault, but that would not be nice.
    • We must change package names when we do the artifact name change. Similar as to Netty's move to netty 3 and 4, which can co-exist on classpath due to other package name.
    • We can not do this, because akka-http-core promised binary compatibility.

Thus, we need to decide if we call it 3.0 or 10.0.
I feel 3.0 may be confusing to people expecting "Akka 3.0", however perhaps that is not an issue...

So final question is on: 3.0 vs 10.0.

@2beaucoup
Contributor

So final question is on: 3.0 vs 1.0.

Should be 10.0?

One more reason against 1.0: https://www.versioneye.com/java/se.scalablesolutions.akka:akka-http/1.0. 😄

@ktoso
Member
ktoso commented Sep 13, 2016

lol, yes I meant 10 there.

@2beaucoup
Contributor
2beaucoup commented Sep 13, 2016 edited

I'm in favor of 3.0 since it's "less weird"™.

Changing artifact group name to com.lightbend.akka (from com.typesafe.akka) during the HTTP move

That's the group-id, right?

@ktoso
Member
ktoso commented Sep 13, 2016 edited

Changing artifact group name to com.lightbend.akka (from com.typesafe.akka) during the HTTP move

That's the group-id, right?

Yes (fixed)

@ktoso
Member
ktoso commented Oct 17, 2016

Summing the thread up: it seems not many people opted for 10.x, and some were ok with 3.x.
Other options are not really viable.
We do anticipate to move forward that number before Akka 3.0 hits, so some ambiguity will exist but we hope to address it when it hits.

We'll release a 3.0.0-RC1 today (once one more PR is merged).
Thanks for all your opinions on this subject!

@ktoso ktoso closed this Oct 17, 2016
@ktoso ktoso removed the 3 - in progress label Oct 17, 2016
@drewhk
Member
drewhk commented Oct 24, 2016

Too late to the party, but ugly is not a valid argument for me. It is not a beauty contest, and it minimizes version clashes. We don't know what Akka 3.0 will break and given that we break things rarely, we might break a lot. Then, akka-http 3.0 will not be compatible with Akka 3.0, so the confusing situation will be that you use akka-http 3.0 with akka 2.0 and akka-http 4.0 with akka 3.0. I still really don't get what is objectively wrong with 10.0 (no, the "it looks ugly" is not an objective argument here).

@ktoso
Member
ktoso commented Oct 24, 2016 edited

While I agree with you it seems no-one else does agree with us Endre...

I made a poll to see how people in general react: https://twitter.com/ktosopl/status/790495668418772992

Technically it'd be last call to change things.

The discussion here has died down kind of, and I've started with the path of least resistance but I'm still not quite sure we're doing the right thing with 3.0.

@patriknw
Member

I think the reasoning was that when we eventually do a Akka 3.0 everyone will be using Akka Http >= 4.0 and they would not accidentally downgrade that to a lower version. Might still be confusing for new users, though. On the other hand we will have many different sub-projects of akka-* all with their own versioning numbers. The time of one single version number is over anyway.

That said, I also think 10.0 would be better.

@jlprat
Contributor
jlprat commented Oct 24, 2016

Just a side note, using akka-http 10.0 means that we post-pone the headache whenever akka 10.0 is released. ;)

Jokes aside, I'm in favor of akka-http 10.0

@jlprat
Contributor
jlprat commented Oct 24, 2016

BTW, @ktoso shouldn't you re-open this task?

@ktoso ktoso reopened this Oct 24, 2016
@ktoso
Member
ktoso commented Oct 24, 2016

True, let's do one last round of versioning debate including the community at large (twitter poll).

I'm sorry for not being very dictator-ish about it–we would have solved this already if I was–hope people appreciate our reach out about this decision.

@guidomedina

I would had voted 3.0.0 but I have no Twitter or any social media account for that matter.

@drewhk
Member
drewhk commented Oct 24, 2016

We will manually add one then ;)
@ktoso for dictator!

@ysihaoy
ysihaoy commented Oct 24, 2016

I would like to version with Akka-http 3.0.0 because it's the best option. As jump from 2.4.11 to 10.0.0 is really weird not quite what our community does :-)

@ktoso
Member
ktoso commented Oct 24, 2016 edited

"Weird" is not an argument.

3.0 will cause compatibility issues as well as googlability issues:

  • person writes blog on akka http 3.0. 2 years later someone looks for "how to do ... in akka 3", yet finds the akka-http 3.0 blog post. It's not compatible, since 3.0 will focus on Akka Typed. They're left crazy confused and up to themselfes to figure out what's happening.
  • people have builds with val akkaVersion = "..." and expect that to work. It would pull in Akka HTTP 3.0 (very old by then), and (very new) Akka (Typed) 3.0 – causing blow ups.

The counter argument that 10.0 "weird" is a really weak argument in face of a lot of compatibility issues and confusion we (the team, and community) would have to deal with calling it the 3.0.

I admit having been "weak" and giving in to the path of least resistance and starting the RC1 with 3.0, but still feel it would be the wrong thing to do. In face of lacking proper counter arguments, and strong preference of @akka-team and @akka/akka-http-team I think doing the right thing even if weird is the better thing for everyone.

We're still looking at the twitter poll, but I feel some people may be voting on gut feeling, without thinking about all the compatibility issues one or the other address.

Note also that "weird" was also the case for Netty, which changed entire package structure in order to allow 3 and 4 to love side-by-side. Is it something many projects do? No. Was it absolutely needed? Yes.


@ktoso for dictator!

"I don't want to be an emperor" 😉

@dwijnand
Contributor

To really solve the googlability issues it would be best to rename the project, when splitting it out of Akka. Then you can use 1.0.

@guidomedina

There is reactive-streams which one implementation is akka-streams, one could think of reactive-http?

Maybe too late but not so far fetched.

@jlprat
Contributor
jlprat commented Oct 24, 2016

Renaming to reactive-http would mean that it's some kind of standard and then different projects are implementing it. AFAIK this is not the case with akka-http. And at the end akka-http, it's highly related with Akka as it's build on top of it.

@guidomedina
guidomedina commented Oct 24, 2016 edited

@jlprat yeah, you are right about that, the word reactive in front would make it too generic, any other combination I can find in my head sounds stupid, like: akka-streams-http

@michaelzg

If next version is to be "3" ish number then we can do it in binary and have it be 11 (and then count in binary until Akka 3.0 comes out before going back to decimal). Not so far off from 10.

:)

@relgames

The pool is not correct. You should have one more option: don't touch what is not broken.

This is the second time versions change, and it is confusing again.
3.0 or 10.0 just adds more confusion but adds no value.
I got used to changing akka version in a single place for everything, including http.

If you want to release it faster, just release, like you do now. The whole discussion reminds me about a bike shed color problem.

@viktorklang
Member

So how do you propose breaking changes are dealt with?

Cheers,

On Oct 25, 2016 20:28, "Oleg Poleshuk" notifications@github.com wrote:

The pool is not correct. You should have one more option: don't touch what
is not broken.

This is the second time versions change, and it is confusing again.
3.0 or 10.0 just adds more confusion but adds no value.
I got used to changing akka version in a single place for everything,
including http.

If you want to release it faster, just release, like you do now. The whole
discussion reminds me about a bike shed color problem.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAqd-28j93kmg8y632phiqhxeNVuERkks5q3koxgaJpZM4Jqoyg
.

@relgames

@viktorklang release notes, for example.

Breaking changes means akka-http is not stable enough and it was too early to make it a part of akka; it could just stay -experimental if there are so many breaking changes.

@ktoso
Member
ktoso commented Oct 25, 2016 edited

There is a huge difference in how akka "core" is used an how akka http directives are used, one is at the core of many open source projects, and the directives are at the "last mile" (people compiling their http apps. HTTP has the largest surface area for changes and it should not force an Akka 3.0 since that we want to be Akka Typed.

"Because I got used to" 1 val for "akka version" is hardly a reason to determine how versioning should happen moving forward. So I find that argument to be on the same level as "looks weird" - not very helpful. One could argue getting them in the same versioning scheme was not a good idea in the first place - though but the nature of its development "together with" Streams it made sense.

No answer here will satisfy everyone, as the pool confirmed.
It's purpose was to check if some option would vastly be prefered by the community at large, but this did not happen - the split is mostly even, thus we'll do what causes the least pain to newcomers and "our future selfs" (by us I mean the existing community, as well as maintainers).

It should also be noted that already there exists no "the akka version", since we have akka plugins for persistence (separate versions), kafka (separate versions), alpakka (separate versions) as well as akka-stream-contrib (separate versions). The days of one version number are already gone.

So no, the same versioning scheme can not remain.
The bikeshed will be painted and released end of this week we hope.

@relgames

Spring Boot consists of many different components and versions, and they use so called "release trains": BOM files are released once in a while, containing explicitly specified versions of different components that 100% work with each other.

But I guess it's not an option for Akka as there is no Maven.

I think 10.0 is fine. We have Guava 19 and Chrome 49 and it's fine.

@viktorklang
Member

How will Ivy/Maven use those notes to pick the right version when multiple
different versions of transitive dependencies are found?

Cheers,

On Oct 25, 2016 22:00, "Oleg Poleshuk" notifications@github.com wrote:

@viktorklang https://github.com/viktorklang release notes, for example.

Breaking changes means akka-http is not stable enough and it was too early
to make it a part of akka; it could just stay -experimental if there are so
many breaking changes.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAqd23zUImv0qnzn3On4rP4MH72WgOyks5q3l_6gaJpZM4Jqoyg
.

@viktorklang
Member

How do these BOM-files solve the problems of binary-incompatible minor
versions in transitive dependencies?

Cheers,

On Oct 25, 2016 22:38, "Oleg Poleshuk" notifications@github.com wrote:

Spring Boot consists of many different components and versions, and they
use so called "release trains": BOM files are released once in a while,
containing explicitly specified versions of different components that 100%
work with each other.

But I guess it's not an option for Akka as there is no Maven.

I think 10.0 is fine. We have Guava 19 and Chrome 49 and it's fine.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAqd1uYmoxycZ9PrYPGkUoI5HdZjJDEks5q3mjXgaJpZM4Jqoyg
.

@ktoso
Member
ktoso commented Oct 25, 2016 edited

FYI: The "I just want a version of all the stuff that works" will be addressed by the ScalaCenter rolling out "stacks". Those would be human curated AFAIK.

I think we're pretty much ready to call a decision tomorrow here.
Thanks everyone for participating, the community and contributor feedback was very valuable, thank you.

@relgames
relgames commented Nov 2, 2016

So, what is the final decision?

@sirocchj sirocchj referenced this issue in lomigmegard/akka-http-cors Nov 10, 2016
Merged

- bumped scala to 2.12.0 #6

@ktoso
Member
ktoso commented Nov 11, 2016 edited

The final decision, after taking all of the comments from the teams and communities into account, is that we'll call the stable version 10.0.0.
See my previous posts explaining why this version is safer than the other ones, even if "weird". We did not get any productive counter argument that would defend the choice of "3.0" reasonably enough to keep the use of it. We specifically value less confusion, and long term ease of googling more than avoiding something looking a bit weird.

We published 10.0.0-RC2, will announce very soon, and then hopefully call a stable from that.
It will support Scala 2.12 on day one (the RC2 already does).

This is the final decision. It's just a number, and we've spent way too much time debating it already.
For those who want to "just pick one version and get all the latest Akka stuff" you'll be pleased to hear that the Scala Center will be working on a concept called "stacks" that will allow us to bundle up libraries into a shared "super dependency". It's in it's early days and not yet really announced. We keep this in mind though, and think that the "weird number" is much less harm than potentially confusing people who'd bump into different meanings of "3.0".

Thank you, everyone, who participated in the discussion.
I really value all of the feedback, and think this decision will be the best for all of the Akka eco-system in the long term. Thanks!

@ktoso ktoso closed this Nov 11, 2016
@ktoso ktoso self-assigned this Nov 11, 2016
@sirocchj sirocchj referenced this issue in swagger-api/swagger-scala-module Nov 12, 2016
Merged

- adding cross-compilation to 2.12.0, bumped all versions #25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment