2.0.0-rc1 (2021-11-28)

[brendanhay]

The Amazonka team is happy to announce the availability of the first release candidate for the upcoming 2.0.0 release. This release collects the past few years' worth of bug fixes and AWS service updates, and also includes some fairly major changes to repository organisation and conventions. Some of the highlighted changes include:

• Sum types for enumerations have been replaced with pattern synonyms over Text, this makes all sum types trivially extensible - no more deserialisation errors when EC2 adds new instance types, regions, etc.
• The core Network.AWS namespace has been renamed to Amazonka to match the package.
• Record field names now match the documentation (where possible) and are no longer prefixed - it is now recommended to use generic-lens or optics packages to modify fields, but generated lenses are still provided for compatibility in each respective Amazonka.<Service>.Lens module.
• The main branch is now the singular source of truth. master + develop will continue to exist in their current state(s), but no further commits will occur on these branches.
• Work has been done to reduce the amount of memory used when compiling large service libraries such as amazonka-ec2.

Please read the Amazonka CHANGELOG.md for a high-level overview of all the other changes included in the release.

Because of the magnitude of the accumulated changes, we are now entering a stabilisation period before we release to Hackage. During this period, we'd greatly appreciate people testing amazonka against their projects, and reporting issues against the 2.0 milestone. We are aiming for a four-week stabilisation period, but may shorten or lengthen this depending on the volume of issues raised.

The large number of changes and improvements is thanks to all of the individuals who contributed to this release. Big thanks to everyone involved and in particular @endgame for his work driving everything forward.

You can view the latest Haddock documentation which is built against the main branch and published at https://amazonka.brendanhay.nz/ .

To test the release, you will need to add a source-repository-package section to your cabal.project file for amazonka itself, and for any service libraries you use (amazonka-sts and amazonka-sso are now dependencies of amazonka because of sts:AssumeRoleWithWebIdentity and SSO support):

-- For amazonka
-- Multiple subdirs in a single `source-repository-package` stanza are supported by cabal-install >= 3.2.0.0.
source-repository-package
    type: git
    location: https://github.com/brendanhay/amazonka
    tag: <current revision of the `main` branch>
    subdir: lib/amazonka lib/amazonka-core lib/services/amazonka-sso lib/services/amazonka-sts lib/services/amazonka-<servicename>

Stack users should use an extra-deps: stanza like this:

extra-deps:
- github: brendanhay/amazonka
  commit: <current revision of the `main` branch>
  subdirs:
  - lib/amazonka
  - lib/amazonka-core
  - lib/services/amazonka-sso
  - lib/services/amazonka-sts
  - lib/services/amazonka-<servicename>

Stack users who also use haskell.nix will need to tell haskell.nix which branch to fetch Amazonka commits from by passing a branchMap parameter like this:

pkgs.haskell-nix.project {
  branchMap = {
    "https://github.com/brendanhay/amazonka.git" = {
      e64638ae16dc6d549d6e7c21262245e29761ede7 = "main";
    };
  };

  # Whatever else you normally have here
  src = ...
}

---

This discussion was created from the release 2.0.0-rc1 (2021-11-28).

[endgame]

Congratulations Brendan, it's been great working with you to get this over the line.

[mmport80]

It looks like SSO is also a requirement now.

Btw, please put some info on the front page README - took me a while to find this page.

[phadej]

optics documentation says in https://hackage.haskell.org/package/optics-core-0.4/docs/Optics-Label.html#g:5

Note: Generic deriving of optics works well on a moderate scale, but for ubiquitous usage (and in production in general) we recommend generating them with Template Haskell as it scales better in terms of compilation time. For more details see makeFieldLabelsNoPrefix from Optics.TH in the optics-th package.

That would be welcome if you recommend optics usage.

[brendanhay]

I'm aware of the cost of Generics vs TH for optics, but I'm on the fence for now as Generics doesn't dictate we commit to using optics vs lens in the external interface for the time being - the next goal being to deprecate the generated lenses and rewrite the internals so we can remove the dependency on the lens library entirely.

If you've the time, an argument or summary for why you would prefer us to recommend/provide exported optics (vs lens, or nothing at all) out of the box would be appreciated.

[phadej]

If the goal is to remove lens dependency, then it's "fair" that both optics and lens users suffer from compile time of their applications (when they use generics). It might be RecordDotSyntax gets proper setter support in GHC-9.4 or 9.6, and that will be fine (and lens or optics users can built on top).

[phadej]

Note that for HasFields to work, the data type constructors have to be exported. Luckily they are in amazonka-2 service libraries.

[brendanhay]

Everything will be exported by default, moving forward. The previously hidden constructors was a mistake/misfeature.

[phadej]

You may further speed up compilation of amazonka service libs by generating Hashable and NFData instances (and not relying on Generic-based defaults). Especially if there are bigger product types (= a lot of fields) the speedup can be actually noticeable. Given the code is generated anyway, I don't think that would be a big change.

[brendanhay]

It would be fairly trivial to do, I'll look into it - thanks.

[endgame]

Captured as #719

[jhrcek]

Hello @brendanhay , thanks for all the effort towards releasing 2.0!
We at Holmusk depend on amazonka libs heavily, so I'm eager to try out 2.0-rc1.

Just letting you know, that I had to fight stack dependency solver for a bit before I figured out the proper configuration for stack.yaml

Just to use amazonka-ec2, I had to do add amazonka-core (because every service lib depends on it) and amazonka-sts (dependency of amazonka) directories.
You might want to update the stack setup exaple in release notes to spare people some figuring out.

extra-deps:
  - github: brendanhay/amazonka
    commit: <current revision of the `main` branch>
    subdirs:
      - lib/amazonka
      - lib/amazonka-core # every service library (like ec2, s3) depends on this
      - lib/services/amazonka-sts # 'amazonka' library depends on this
      - lib/services/amazonka-<servicename>

Also here's the amazonka libraries dependency graph just for reference (generated by running stack init && stack dot | dot -Tsvg -Nshape=rect -Grankdir=LR -o amazonka-library-denepdencies.svg in the amazonka repo root, where dot comes from graphviz package):
https://gist.github.com/jhrcek/9ccb086cd3d0a0253f22798a9780e688

[endgame]

Thanks. I have updated the OP - amazonka now depends on amazonka-sts for AssumeRoleWithWebIdentity support (used by certain EKS setups among other things). sts:AssumeRole support is also planned at some point.

P.S.: We appreciate you trying RC1 on commercial code - while I've been running various test programs along the way, the only way we get a good release is if people put in the hard yards over the next few weeks.

[bsaul]

Minor typo in the example cabal.project:

      subdir: lib/amazonka lib/amazonka-core lib/service/amazonka-sts lib/service/amazonka-<servicename>

s should be added to service:

      subdir: lib/amazonka lib/amazonka-core lib/services/amazonka-sts lib/services/amazonka-<servicename>

[brendanhay]

Thanks for catching that - I've corrected the example.

[bsaul]

Thank you @brendanhay et al for all your efforts. I was able to upgrade to 2.0.0-rc1 without too much trouble, though my needs are pretty simple at this point (just getting and putting to/from S3). The examples were quite helpful.

[m4dc4p]

Really appreciate your work! I was able to upgrade our large (500+ modules) codebase with a couple days work (mostly due to downstream dependencies that also need to be updated).

The biggest cause of churn was the removal / moving of lenses. For example, we used envRegion all over. I just updated to use the record selector directly, rather than add another import as Lenses are now deprecated.

If there is a recommended approach please let me know.

Thanks again!

[endgame]

The eventual plan AIUI is for amazonka to be agnostic about which lens/optics library developers might want to use, and delegate their eventual generation to generic-lens or similar.

For manipulating the Env specifically, record selectors/updates are fine but you can also use combinators like within :: Region -> Env -> Env which is exported by the Amazonka module.

[endgame]

P.S. you can check the examples for two different ways to use generic-lens: one using the field function and type applications, and the other using -XOverloadedLabels.

[mbj]

Cannot disclose the customer, but I've upgraded to amazonka-2 nicely without any issues. Overall our code got a tiny bit nicer, mostly as it was easier to integrate amazonka-2 in our effect framework. Well done.

[jappeace]

Hi, thanks for your hardwork. but could you please make a release on hackage?
Our package config has a comment we need to use master due to a critical bug in amazonka "multi-part uploads fail due to a bad header".

[endgame]

Not yet, I'm afraid. There are some serious bugs in the code generator that prevent us from handling new and existing service definitions, and while I have made it partway through a fix I haven't completed that work.

What I do have is time to review PRs: this is how support for sts:AssumeRoleWithWebIdentity and SSO landed in develop. https://github.com/brendanhay/amazonka/milestone/3 is the list of issues assigned to the 2.0 milestone: maybe there's something you can pick off? #747, #728, and #689 might not be too hard.

Our package config has a comment we need to use master

Just checking: you mean main, right? Neither master nor develop are seeing new commits.

[jappeace]

I shall see what I can do, yes I meant main.

[bsaul]

Is there a contributor process for checking out issues to work on? I doubt it would happen, but I want to avoid duplicating work.

[endgame]

No, there isn't, and I don't think the dev community is active enough to warrant one. If you think something is going to take a good chunk of effort, maybe leave a comment on the relevant issue when you start digging?

[DeepakKapiswe]

Hi Guys, Thanks for your hardwork, at the moment amazonka is stopping me the upgrade process to LTS 19.X. Please Release update in Hackage. What is the current status in 2023 ? What other people do, when you guys upgrade your project to latest LTS ?
Is there something we can help ? I believe this is a very important industrial package of real dependency for Haskellers. Thanks again.

[mbj]

@DeepakKapiswe I recommend to use a git source from main its fairly stable. This got me on the latest LTS releases.