{"action":"created","issue":{"url":"https://api.github.com/repos/akka/akka-meta/issues/27","repository_url":"https://api.github.com/repos/akka/akka-meta","labels_url":"https://api.github.com/repos/akka/akka-meta/issues/27/labels{/name}","comments_url":"https://api.github.com/repos/akka/akka-meta/issues/27/comments","events_url":"https://api.github.com/repos/akka/akka-meta/issues/27/events","html_url":"https://github.com/akka/akka-meta/issues/27","id":172114279,"number":27,"title":"Akka HTTP - stable, growing and tons of opportunity ","user":{"login":"ktoso","id":120979,"avatar_url":"https://avatars.githubusercontent.com/u/120979?v=3","gravatar_id":"","url":"https://api.github.com/users/ktoso","html_url":"https://github.com/ktoso","followers_url":"https://api.github.com/users/ktoso/followers","following_url":"https://api.github.com/users/ktoso/following{/other_user}","gists_url":"https://api.github.com/users/ktoso/gists{/gist_id}","starred_url":"https://api.github.com/users/ktoso/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ktoso/subscriptions","organizations_url":"https://api.github.com/users/ktoso/orgs","repos_url":"https://api.github.com/users/ktoso/repos","events_url":"https://api.github.com/users/ktoso/events{/privacy}","received_events_url":"https://api.github.com/users/ktoso/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/akka/akka-meta/labels/discuss","name":"discuss","color":"d4c5f9"},{"url":"https://api.github.com/repos/akka/akka-meta/labels/help%20wanted","name":"help wanted","color":"159818"}],"state":"open","locked":false,"assignee":{"login":"ktoso","id":120979,"avatar_url":"https://avatars.githubusercontent.com/u/120979?v=3","gravatar_id":"","url":"https://api.github.com/users/ktoso","html_url":"https://github.com/ktoso","followers_url":"https://api.github.com/users/ktoso/followers","following_url":"https://api.github.com/users/ktoso/following{/other_user}","gists_url":"https://api.github.com/users/ktoso/gists{/gist_id}","starred_url":"https://api.github.com/users/ktoso/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ktoso/subscriptions","organizations_url":"https://api.github.com/users/ktoso/orgs","repos_url":"https://api.github.com/users/ktoso/repos","events_url":"https://api.github.com/users/ktoso/events{/privacy}","received_events_url":"https://api.github.com/users/ktoso/received_events","type":"User","site_admin":false},"assignees":[{"login":"ktoso","id":120979,"avatar_url":"https://avatars.githubusercontent.com/u/120979?v=3","gravatar_id":"","url":"https://api.github.com/users/ktoso","html_url":"https://github.com/ktoso","followers_url":"https://api.github.com/users/ktoso/followers","following_url":"https://api.github.com/users/ktoso/following{/other_user}","gists_url":"https://api.github.com/users/ktoso/gists{/gist_id}","starred_url":"https://api.github.com/users/ktoso/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ktoso/subscriptions","organizations_url":"https://api.github.com/users/ktoso/orgs","repos_url":"https://api.github.com/users/ktoso/repos","events_url":"https://api.github.com/users/ktoso/events{/privacy}","received_events_url":"https://api.github.com/users/ktoso/received_events","type":"User","site_admin":false}],"milestone":null,"comments":29,"created_at":"2016-08-19T11:49:04Z","updated_at":"2016-09-08T19:40:53Z","closed_at":null,"body":"Dear hakkers,\r\n\r\nAfter the recent Akka HTTP [performance](http://akka.io/news/2016/08/02/akka-2.4.9-RC1-released.html) [improvement](http://akka.io/news/2016/08/02/akka-2.4.9-RC2-released.html) releases, it is time to prepare for the Stable release of Akka HTTP.\r\n\r\nWe have given this process a lot of thought over the last months, including reaching out personally to many of its significant contributors, as well as considering the long term [growth](http://githubstats.com/akka/akka) plans of the Akka ecosystem. \r\n\r\nIn tandem with the upcoming announcement of Akka HTTP becoming a fully stable maintained module, we want to include the following changes.\r\n\r\n## You, the extended Akka HTTP team\r\n\r\nAkka has historically been very strictly owned and driven by the core team, here at Lightbend. With this move, we would like to make an experiment and see if our awesome community is able and interested in taking more ownership and direction-shaping of such an important project as Akka HTTP.\r\n\r\nLightbend and Akka team of course remain heavily invested and interested in Akka HTTP.\r\n\r\nWe believe it is an important building block for both Akka and reactive applications which like the toolkit (i.e. not-framework) design style that Akka maintains.\r\n\r\nAkka HTTP remains supported by Lightbend and we will actively participate in its development. In the short term we promised a few weeks of multiple people working on HTTP/2 as well as final performance improvements. In the long term, we will keep maintaining, reviewing, and working on it, however unlike in the last 2 years we will not exclusively focus only on Akka Streams and HTTP – we have new exciting thing we want to bring to you which you’ll learn about very soon (one of them being the Remoting rewrite, [Artery](https://github.com/akka/akka-meta/issues/16)).\r\n\r\n**Action:** This is simply to state, there is a lot of work to be done, and plenty of awesome developers out there that we know are able to pull it off, so we’d like to recognise those efforts by awarding a place for the Akka HTTP team in the github organisation.\r\n\r\n## Highly Open Participation\r\n\r\nAs a general rule, we’ll even more strongly than ever before, focus on a highly open and transparent way to participate and shape the future of Akka HTTP. \r\n\r\nWe would like to nominate a number of people–whom we highly value for their past and current participation in both the Spray as well as Akka HTTP project over the last year–to form the seed of the Akka HTTP team on github. This team is specifically not-only-lightbend employees, and it’s aim is to allow various people with a strong commitment in Akka HTTP to help shape its future and be recognised for it in more than just release notes.\r\n\r\nThe people whom we’d like to invite to form the initial Akka HTTP team are:\r\n\r\n* @2beaucoup – as recognition of his continued involvement in the project since it’s Spray days,\r\n* @jypma – for his continued efforts on improving and re-inventing the Directives JavaDSL,\r\n* @jrudolph – of Spray and Akka HTTP fame, who will be joining us at Lightbend’s Akka team,\r\n* @sirthias and the existing Akka team.\r\n\r\nThe team will have merge rights in the project, so will be able to help the community get more pull requests reviewed and merged more quickly.\r\n\r\nWe initially don’t see the need to split the gitter channel or mailing list, those shall remain [gitter.im/akka/dev](http://gitter.im/akka/dev) for developing akka and [gitter.im/akka/akka](http://gitter.im/akka/akka) and [akka-user](https://groups.google.com/d/forum/akka-user) for questions about using Akka.\r\n\r\n**Question:** We are also thinking about scheduling a bi-weekly hangout, that would be open to anyone to attend in which we’d talk about the direction and important things to work on next. Let us know if this sounds useful and we’ll figure something out. \r\n\r\nIt would be possibly a good opportunity to improve the collaboration in the Akka HTTP team by growing our bonds through more than just typed text and tickets.\r\n\r\n## A new Versioning scheme for Akka HTTP\r\n\r\n[Binary compatibility](http://doc.akka.io/docs/akka/2.4/common/binary-compatibility-rules.html) 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. \r\n\r\nPlease 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.\r\n\r\nWe 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](http://akka.io/news/2015/07/15/akka-streams-1.0-released.html) 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.\r\n\r\nOur 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. \r\n\r\n**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).\r\n\r\n**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.\r\n\r\n## Split documentation\r\n\r\nAkka always was and still is well known for it’s excellent documentation and we intend for it to not only stay this way, but become even better!\r\n\r\nOur largest challenge currently with this came with the growth of documentation pages, especially with the addition of Akka HTTP and it’s more than 300 directives (all directives and pages available in both Scala and Java), it is becoming more difficult to read / browse the entire docs together. \r\n\r\nTherefore, we would like to split up documentation in different module sub-directories. For example, specifically this means that we’ll move all of Akka HTTP docs to a root-level \"http\" directory on doc.akka.io.\r\n\r\nAdditionally we want to move the documentation to [Lightbend Paradox](https://github.com/lightbend/paradox) a documentation engine. It is much simpler to use than Sphinx and ReStructured Text which Akka is using currently because it is plain Markdown. It will shortly gain fine-tuned Scala documentation features and and can even include executable Akka.js snippets using [ScalaFiddle](https://scalafiddle.io/). You can get a glimpse of how [documentation with embedded runnable Akka Streams snippets](https://andreatp.github.io/akkadoc-poc/)  might look like on this example page prepared by Andrea Peruffo (from the [Akka.js](https://andreatp.github.io/akka.js-site/) team).\r\n\r\nAs you know, we included Algolia powered search in our docs so it’s now much easier to find the right thing in the docs. Often however, you are searching for things in context–i.e. \"I’m looking to do X in Akka HTTP\" or specifically looking how to do something with Reactive Kafka. Often similar search queries, and confining the search to a given module will yield in a better search experience.\r\n\r\n**Action:** Docs will be hosted under doc.akka.io/ as is currently, however will be moved to their own top-level directory, e.g. doc.akka.io/http/10.0/. We will attempt (and need help doing it, there’s a ton of documentation) to move from Sphinx to Paradox, which should be much simpler to contribute docs with as it’s plain markdown.\r\n\r\n## Exciting and upcoming: HTTP/2\r\n\r\nAs briefly mentioned in release notes over the last months: yes, we will work on an HTTP/2 proof-of-concept for Akka HTTP. It is important to realise that unlike for example Play which relies on Netty for implementing the HTTP layer and can simply upgrade netty to get this capability, Akka HTTP is an *entire* web server, thus the responsibility of implementing all low level bits of the HTTP/2 protocol fall into the hands of akka-http-core.\r\n\r\n**Action:** We will spend a number of weeks developing an HTTP/2 PoC, however are not sure how much features we’ll be able to implement during that time. When we start the HTTP/2 sprint, we’ll invite you, the interested parties in this feature to review, help, and contribute to get this the best possible support. In other words, with the project becoming more and more community led, we would like to encourage a \"vote with code\" approach–if a feature is important, it should be able to attract contributions to see it shipped.\r\n\r\n## Summing up\r\n\r\nWe believe this move is both important and exciting. It will allow to grow the community not only sheer size but also strength and go where no man has gone before. Feel free to comment in this meta thread if you have any thoughts on the topic.\r\n\r\nMore technical details which we need to decide before calling the module stable will be debated on the [github.com/akka/akka-http](https://github.com/akka/akka-http) repository. For example stating and explicit source compatibility requirement or perhaps deprecating the \"trait-style\" way of using directives to allow us to keep binary compatibility in much more situations.\r\n\r\nAgain, we’d like to stress that we want to hear and see both feedback and code from you all.\r\n\r\nLet’s get hakking!"},"comment":{"url":"https://api.github.com/repos/akka/akka-meta/issues/comments/245715771","html_url":"https://github.com/akka/akka-meta/issues/27#issuecomment-245715771","issue_url":"https://api.github.com/repos/akka/akka-meta/issues/27","id":245715771,"user":{"login":"ctataryn","id":435719,"avatar_url":"https://avatars.githubusercontent.com/u/435719?v=3","gravatar_id":"","url":"https://api.github.com/users/ctataryn","html_url":"https://github.com/ctataryn","followers_url":"https://api.github.com/users/ctataryn/followers","following_url":"https://api.github.com/users/ctataryn/following{/other_user}","gists_url":"https://api.github.com/users/ctataryn/gists{/gist_id}","starred_url":"https://api.github.com/users/ctataryn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ctataryn/subscriptions","organizations_url":"https://api.github.com/users/ctataryn/orgs","repos_url":"https://api.github.com/users/ctataryn/repos","events_url":"https://api.github.com/users/ctataryn/events{/privacy}","received_events_url":"https://api.github.com/users/ctataryn/received_events","type":"User","site_admin":false},"created_at":"2016-09-08T19:40:52Z","updated_at":"2016-09-08T19:40:52Z","body":"@ktoso will there be a decent migration guide available?  I really felt the upgrade guide for Slick 2.1->3.x was highly highly lacking. Which is disappointing because I felt their upgrade guides always covered the bases. If it weren't for the Essential Slick 3 book, I'd be pretty hosed.\r\n\r\nAs it appears I'll have to upgrade to Akka-HTTP I'd be happy to contribute to such a guide."}}
{"actor":{"display_login":"ctataryn"}}