Release plan

[Andersson007]

SUMMARY

(partially copied from ansible-collections/community.crypto#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 ansible-collections/community.docker#4)

@bmalynovytch @bmildren @felixfontein @Jorge-Rodriguez

UPDATE: we agreed on maintaining older (stable*) versions for 2 years (backporting bugfixes, releasing, testing) since the next major version is released. Then we do final releases announcing under major_changes that those versions are EoL.

[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 #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 #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 #97 (comment).

I suggest releasing version 2.0.0 containing at least #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).