Release plan

[Andersson007]

SUMMARY

(partially copied from https://github.com/ansible-collections/community.crypto/issues/74 , thanks to @felixfontein)

We should decide eventually on how to release this collection (w.r.t. versioning). Small collections like this one don't need a complex plan like the one for community.general and community.network. So how about the following?

1. Release minor and patch releases whenever we want (like after adding new features or fixing bugs). Since this collection is small, there's no need to fix things in advance. Just add features, and after a feature either wait a bit longer for more features/bugs, or make a release.

I suggest releasing without branching https://github.com/ansible/community-docs/blob/main/releasing_collections_without_release_branches.rst

Once we release a 2.0.0 (with some breaking change relative to 1.x.y), we can have a stable-1 branch so we can backport bugfixes (or even features) if needed, and release more 1.x.y versions. We currently have some deprecation removals scheduled for 2.0.0 (see #1). Maybe scheduling 2.0.0 roughly for Ansible 2.12 (i.e. next summer) would be a good idea. (the part ^ taken from the description of https://github.com/ansible-collections/community.docker/issues/4)

@bmalynovytch @bmildren @felixfontein @Jorge-Rodriguez

[Andersson007]

Questions:

1. Releasing without branches as described in the description is ok for everyone?
2. I suggest releasing version 1.0.1 on 2020-09-30 (next week Wednesday). As far as I can see, there were only fixes merged since the last release. Any thoughts?

[felixfontein]

This approach is reasonable and a good idea IMO :) For community.crypto, we eventually will have a 2.0.0 version with breaking changes (when removing something we deprecated), and then we'll add a stable-1 branch so we can still backport bugfixes (or even features, if we really want to) to release new 1.x.y versions.

I guess as long as there is no need to make a breaking change, sticking to main branch and versions 1.x.y is a good choice. And your users will also love that, since no breaking change means full backwards compatibility :)

[Andersson007]

community.mysql 1.0.1 has just been released https://github.com/ansible-collections/community.mysql/tags

[Andersson007]

if nobody's against, i would release 1.0.2 on 01.10.2020 (tomorrow) because of https://github.com/ansible-collections/community.mysql/pull/40

[Andersson007]

I've just released 1.0.2

[rndmh3ro]

Release minor and patch releases whenever we want (like after adding new features or fixing bugs). Since this collection is small, there's no need to fix things in advance.

Agreed!

Just add features, and after a feature either wait a bit longer for more features/bugs, or make a release.

Waiting for more features/bugs seems to have no benefit, so I'd say release whenever a new feature is merged or a bug is fixed.

[Andersson007]

@rndmh3ro welcome!:)

[Andersson007]

I've just release 1.1.0

[Andersson007]

I'd like to release 1.1.1 today's evening @Jorge-Rodriguez do you have anything to include that you almost finish but that's not yet published? We could postpone this for a couple of days.

[Andersson007]

I've just released 1.1.1

[Andersson007]

I've just released 1.1.2

[Andersson007]

community.mysql collection 1.2.0 has just been released. The tarbal is available on Galaxy. How to install it, see the official guide. The changes will also be included in the next Ansible release.

[Andersson007]

I'm going to release community.mysql 1.3.0 after https://github.com/ansible-collections/community.mysql/pull/62 is merged

[Andersson007]

@Jorge-Rodriguez @bmalynovytch @bmildren I've just add the following to the description:

Once we release a 2.0.0 (with some breaking change relative to 1.x.y), we can have a stable-1 branch so we can backport bugfixes (or even features) if needed, and release more 1.x.y versions. We currently have some deprecation removals scheduled for 2.0.0 (see #1). Maybe scheduling 2.0.0 roughly for Ansible 2.12 (i.e. next summer) would be a good idea.
(the part ^ taken from the description of ansible-collections/community.docker#4)

We could align the major releases with Ansble major releases as @felixfontein suggested in https://github.com/ansible-collections/community.mysql/pull/97#issuecomment-785921194.

I suggest releasing version 2.0.0 containing at least https://github.com/ansible-collections/community.mysql/pull/97 in a month before Ansible 5.0.0 - a bit more than in 6 months.

======================================================== The following major changes will be (we will update this list when needed): 2.0.0

- mysql_replication - the word ``SLAVE`` in messages returned by the module will be changed to ``REPLICA`` in ``community.mysql`` 2.0.0 (https://github.com/ansible-collections/community.mysql/issues/98).

3.0.0

- mysql_replication - the mode options values ``getslave``, ``startslave``, ``stopslave``, ``resetslave``, ``resetslaveall` and the master_use_gtid option ``slave_pos`` are deprecated (see the alternative values) and will be removed in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/pull/97).

[Jorge-Rodriguez]

@bmalynovytch @bmildren I'd like to move the discussion on #101 forward before we release v2

[Andersson007]

Tomorrow there will be Ansible 3.1.0 release, so I'll release this collection now to get things included

[Andersson007]

community.mysql 1.3.0 has been released

[Andersson007]

1. according to the 2.11 roadmap, the expected release date of 2.11 is 2021-04-26, I suggest releasing community.mysql 2.0.0 ~in mid-April
2. according to the 2.12 roadmap, the expected release date of 2.12 is 2021-10-25 I suggest releasing community.mysql 3.0.0 ~in mid-October

The dates can be adjusted later. СС @Jorge-Rodriguez @bmalynovytch

[Jorge-Rodriguez]

LGTM, I'll have to hurry with the REQUIRESSL thing, so that's next on my table

[Andersson007]

FYI: As planned, I'm releasing community.mysql 2.0.0 tomorrow morning (2021-04-15)

[Andersson007]

community.mysql 2.0.0 has been released

New branch stable-2 has been created as well

@Jorge-Rodriguez @bmalynovytch it means that we have to backport to stable-2 (by cherry-picking from main) all changes we'll merge to main since now (except breaking changes!). I created a label needs_backport_to_stable-2 - please put it on all PRs you'll merge since now, then create backports. Thanks! Don't put this label on PRs with breaking changes! :)

Thanks!

[Andersson007]

So we're planning the next (3.0.0) major release ~in mid-October

[Andersson007]

fyi: stable-1 has been created as well. I've just released community.mysql 1.4.0. We'll backport only bug / security fixes to stable-1

[Andersson007]

I'm going to release community.mysql 1.4.1 and 2.1.0 later today

[Andersson007]

community.mysql 1.4.1 and 2.1.0 have been released

[Andersson007]

I'm gonna release community.mysql 2.1.1 and 1.4.2 tomorrow morning.

[Andersson007]

also there will be a dev version of 2.2.0 released tomorrow later or on Thursday

[Andersson007]

community.mysql 1.4.2 and 2.1.1 have been released

[Andersson007]

community.mysql 2.2.0-a1 has been released and available to install via galaxy or directly from https://galaxy.ansible.com/community/mysql. It contains the mysql_role new module. Any feedback would be much appreciated.

[Andersson007]

I'm gonna release 2.2.0 tomorrow 23.09.2021 (it's pity that nobody has tested mysql_role module so far, see the previous comment...)