This document simply outlines the release process:
-
Ensure you are running on the oldest supported Erlang version
-
Remove all
-dev
extension from versions (see below for all files) -
Ensure CHANGELOG is updated and add current date
-
Commit changes above with title "Release vVERSION" and generate new tag
-
Run
make clean test
to ensure all tests pass from scratch and the CI is green -
Recompile an existing project (for example, Ecto) to ensure manifests can be upgraded
-
Push branch and the new tag
-
Publish new docs with
make publish_docs
, copy docs todocs/stable
if appropriate, and push to GitHub Pages -
Publish new zips with
make publish_zips
, uploadPrecompiled.zip
andDocs.zip
to GitHub Releases -
Add the release to
elixir.csv
file inelixir-lang/elixir-lang.github.com
-
Create a new branch "vMAJOR.MINOR"
-
Set
DOCS=vMAJOR.MINOR
andCANONICAL=stable
in Makefile and copy them todocs/stable
(change index.html accordingly) -
In master, bump versions, start new CHANGELOG, add
-dev
back and commit "Start vVERSION+1"
- VERSION
- CHANGELOG.md
- src/elixir.app.src (not lib/elixir/src/elixir.app.src)
Elixir deprecations happens in 3 steps:
-
The feature is soft-deprecated. It means both CHANGELOG and documentation must list the feature as deprecated but no warning is effectively emitted by running the code. There is no requirement to soft-deprecate a feature.
-
The feature is effectively deprecated by emitting warnings on usage. In order to deprecate a feature, the proposed alternative MUST exist for AT LEAST two versions. For example,
Enum.uniq/2
was soft-deprecated in favor ofEnum.uniq_by/2
in Elixir v1.1. This means a deprecation warning may only be emitted by Elixir v1.3 or later. -
The feature is removed. This can only happen on major releases. This means deprecated features in Elixir v1.x shall only be removed by Elixir v2.x.