IMPORTANT: New Release Mechanics

We are updating our branch / release / tag strategy. Please read this if you use ATK for production projects.

EDIT: 0. Semantic Versioning as of 2.1.
All ATK core repositories will follow Semantic versioning:

  • Patch releases (2.1.0 -> 2.1.1) - occasional fixes from those who use ATK in production (see below)
  • Minor releases (2.1 -> 2.2) - may contain breaking changes, but should be easy to migrate and some level of backward compatibility.
  • Major releases (2 -> 3) - those releases will be aimed at removing backward compatibility.

For example - version 2.1 introduces “Button::addTo($x)” mechanic, and makes it a default format. Our older ($x->add(Button)) will remain supported until 3.x (or longer).

:exclamation:We advise your to use composer version constrain with 2 digits (e.g. ~2.1) for development and 3-digits (~2.1.1) for production. Watch out for Announcements on https://forums.agiletoolkit.org/ for upgrade instructions.

1a. Legacy branches
We are adding legacy/2.0 to all repositories - this branch uses older unit / style tests, we just want to leave those alone.

1b. Release branches
All releases starting from 2.1 will create and keep a branch (release/2.1). Patches will be committed directly into this branch along with a new tag (2.1.1).

We used “release/1.3.2” style branches before. We will now only create new branch for releases (e.g. release/2.1).

2. Development Branch
The development branch will produce new major release once every few months, when there are enough pull request marked with “Breaking Changes” label. Accepting breaking changes will help ATK gradually become more mature and adopt new features. There will be several people who could do releases (initially myself and DarkSide66).

https://ui-develop.agiletoolkit.org/ will now be running demo off “develop” branch (and therefore may break)

3. Master branch
We will drop “master” branch all-together. It was a source of merge conflicts in the past and it’s benefit is unclear.

4. Version parity
We will keep version releases coordinated between core repositories. (E.g. atk4/data v2.1 corresponds with release of atk4/ui v2.1).

Composer dependencies would be working consistently so you can easily switch your project between major versions.

5. Release announcements
After new versions are released in all repositories, we will also post announcement in this forum explaining what are the new exciting features are there in the new version and how to use them.

Announcement for ATK 2.1 is coming soon!

I’ve amended my post:

  • will use legacy/v2.0 branch but after that we will stick with release/2.1, release/2.2 for consistency
  • i propose we drop “master”, do we need it?
  • no PRs for releases as @mvorisek suggested be auto-commits followed by adding a tag.

I don’t think we need master