[Release]: v1.1 offical release - CHANGELOG discussion

[Willmish]

Features and PRs to be included in the v1.1 release

Repurposing the issue as its most relevant to the CHANGELOG for v1.1. Current WIP version is sitting in dev, merged in #338 (https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/CHANGELOG.md).

Actions needed before v1.1:

• Review CHANGES that happened to the project since v1.0 and collect them here to be added to the CHANGELOG file if not there already
• Amend PR template / CONTRIBUTING file to include amending the CHANGELOG file on incoming PRs with big enough changes. This is to not lose track of changes that happened over time and the file CAN be bloated in dev, then later trimmed down before an official release.
• To consider - should ADR references go in the CHANGELOG? (ADRs that got implemented/accepted/rejected in between versions?
  • Mentioned in 🎯2023-04-25 Carbon Aware SDK Weekly Meeting Agenda  #337:

  What we need to consider: Tracking which ADRs that are accepted got implemented/and which might be missing (on example of ADR 14 and ADR 6 - ADR 6 already is accepted and mentions dynamic datasource registration and was not implemented)

[nttDamien]

#261

[Willmish]

Binary release as a GitHub package (mentioned during #307 by @YaSuenag )

Creeate a CI/CD workflow (GH Action) to automatically release this

[danuw]

Shall we close #205 and revisit https://github.com/Green-Software-Foundation/carbon-aware-sdk/issues?q=is%3Aissue+is%3Aopen+label%3Av1.1 ?

[Willmish]

Features we definitely might want:

• Seperation of Carbon Intensity Datasource into Emissions Data Source and Forecasting Data Source
• EM Paid support
• EM free support ?

[YaSuenag]

#149

[nttDamien]

#261 's implementation is #300

[vaughanknight]

/locations sevice

[Willmish]

Repurposing the issue as its most relevant to the CHANGELOG for v1.1. Current WIP version is sitting in dev, merged in #338 (https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/CHANGELOG.md).

[bderusha]

should ADR references go in the CHANGELOG? (ADRs that got implemented/accepted/rejected in between versions?

I think the answer depends on who the audience is for the changelog. If the changelog is meant to serve users/operators, I don't think that ADRs are relevant to them because they do not represent a change in how they use the software. If it is meant to serve contributors, then ADR decisions become relevant changes to the project direction that contributors should be aware of.

Personal opinion: changelogs work best when they are for users/operators because that group is likely to review a changelog before doing version upgrades. Contributors are less likely to review a changelog before contributing.

[Willmish]

Update #355: need to aggregate comments from PRs - waiting for GH Copilot X to be enabled to use it for collecting comments from PRs for the CHANGELOG.

• need Add 4-release.yaml to publish container image for the release #342 in for images to be included with the release

[Willmish]

Update: #362:

• Approval for GH Copilot X hasn't come through yet, decision to move forward with v1.1 - @vaughanknight to write up a further CHANGELOG.

[Willmish]

Update #363:

• Waiting for next version of CHANGELOG
• Decision on v1.1 release and further releases: Approve it on a call with main chair present (@vaughanknight ) and then can release during the week - hence we will not be releasing this during this week.

[danuw]

@Willmish I think we can close this now right ? (by #377)

cc @vaughanknight

[Willmish]

Closing as v1.1 is now released.