Release plan

[Andersson007]

SUMMARY

(partially copied from ansible-collections/community.crypto#74 , thanks to @felixfontein)

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/wiki/ReleasingCollections#releasing-without-release-branches-for-smaller-collections
Breaking changes don't work with this schema but we might change the approach and start releasing from branches when needed.

[Andersson007]

I'm going to release 1.2.0 today
#130

[ssbarnea]

@Andersson007 Any idea when the next release will be coming?

I recently seen an important bugfix made by @sshnaidm on #229 and I need a new release in order to be able to add it as a dependency for molecule-podman module.

[Akasurde]

@ssbarnea @Andersson007 I would like to get this #223 merged before we do the release.

[sshnaidm]

we also will need #230

[Andersson007]

@ssbarnea good question
CC @saito-hideki , am I right that you recently became a maintainer of the collection? What do you think of releasing it (after @Akasurde 's PR is merged)?

[saito-hideki]

Hi @Andersson007, Yeah, I am a newcomer :)
I agree. I think it is reasonable for me to cover #223, #229, and #230. Also, it is my understanding that #227 is generated from docstring at release time. If my understanding is correct, I will make a change request to fix firewalld.py side instead of the RST file(docs/ansible.posix.firewalld_module.rst) before release. What do you think about this idea?

[Andersson007]

For me personally, as releases don't happen frequently here (the last one was on March 8), it feels sensible to wait for important things that are almost ready. Anyway, i would establish and announce a tentative release date right now to motivate the folks finish / find reviewers for their work before that date:)

[Akasurde]

@Andersson007 @saito-hideki Let us target 8th August 2021, which will give everybody enough time to do their tasks. What's say?

[saito-hideki]

@Andersson007 @Akasurde I agree with you guys. thanks! :)

[Akasurde]

1.3.0 released on 11 Aug 2021

[saito-hideki]

Dear Maintainers,

The next release 1.4.0 is scheduled for the first week of June. Please feel free to comment here if you have any opinions or concerns about that :)

Thanks!

[chriscroome]

When the next release it made could it be released here, previous ones have only been tagged -- I'd like to be able to use Ansible tasks like the following to get the latest version number:

- name: Use a HEAD request to get the latest redirect URL
  ansible.builtin.uri:
    url: "https://github.com/ansible-collections/ansible.posix/releases/latest"
    method: HEAD
    status_code: 302
    follow_redirects: none
  check_mode: false
  changed_when: false
  register: latest_headers

- name: Set a fact for the latest version
  ansible.builtin.set_fact:
    latest_version: "{{ latest_headers.location | urlsplit('path') | basename | string }}"

[felixfontein]

@saito-hideki I think it would make sense to get a release out as soon as possible for #362 to make sure that the currently released version (to be included in Ansible 5.9.0 and Ansible 6.0.0) does not have the license problem anymore. (See also #362 (comment).)

[felixfontein]

(Ansible 6's feature freeze is tomorrow, so that's the last point in time where a new minor release can make it into Ansible 6. From then on its only bugfix releases until June 7th. See https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_6.html#release-schedule)

[saito-hideki]

@felixfontein I see that the situation.
@Akasurde @Andersson007 if you guys are OK, I'll start the release process.

[saito-hideki]

@felixfontein @Akasurde @Andersson007
I would appreciate it if you could review #363, once it is approved I will continue the release process.

[Akasurde]

@saito-hideki Thanks. I added my approval.

[saito-hideki]

Hi @Akasurde @Andersson007 @felixfontein @chriscroome @akira6592

1.4.0 has been released.
Thank you for all your help :)

[richm]

When is the next release? The rhel_facts module is unusable without #434

[saito-hideki]

Hi @richm
I understand that 1.5.1 has some issues. So I'm planning the next 1.5.2 release this month.

[saito-hideki]

@Akasurde @maxamillion @Andersson007
I'm planning the next 1.5.2 release next week. Please let me know if you have any problems with this.

[maxamillion]

Release early, release often! 🙂

(Seriously, go for it. I'm good with it.)

[saito-hideki]

Hi All,
1.5.2 has been released :)

[saito-hideki]

1.6.0 has been released #565 :)

[saito-hideki]

@felixfontein @Andersson007 @Akasurde @maxamillion

I plan to release a new version in the next few days to address the following issues.
The primary purpose of this release is to correct the incorrect version number, but it also includes some minor changes.

• Violation of semantic versioning #463
• Versioning and deprecation

Current Release Plan

1. Create new stable-1 branch from 4f0114e
2. Add duplication notice for skippy plugin to stable-1 and main branch
3. Release new version 1.6.1 from stable-1 branch includes duplication notice
4. Bump version to 1.7.0 in galaxy.yml on stable-1/ branch
5. Bump version to 2.0.0 in galaxy.yml on main/galaxy.yml branch

Please let me know your opinions.

[felixfontein]

Why not simply create stable-1 from main, then revert f4baa4c (the only feature merged since the 1.6.0 release) and the skippy removal, do the 1.6.1 release, and then revert the reverted f4baa4c? That way you have other bugfixes and maintenance commits like 5321a9e included in stable-1 and the 1.6.1 release.

It might also make sense to do all this on main instead and only branch afterwards, and then again remove skippy from main (but not from stable-1). That way the changelog entry for 2.0.0 will include the skippy removal for 2.0.0 again, instead of having it included only in the 1.6.0 changelog entry.

[saito-hideki]

Hi @felixfontein @Andersson007
Thanks for your help!
I have created stable-1 from main branch. If it is not what you intended, please let me know.

• https://github.com/ansible-collections/ansible.posix/tree/stable-1

1. Two minor-changes f4baa4c and 0821768 have been reverted.
2. skippy plugin removing change 9a2ddcd has been reverted.
3. I left trivials and bugfixes as is.

If you all are OK, I would like to add deprecate notifications to skippy plugin on stable-1 and proceed with the release process for 1.6.1.

Thanks again.

[felixfontein]

There needs to be a changelog entry for cd43bd1.

[saito-hideki]

@felixfontein Thanks for the kind advice :)
Based on your advice, I added a message to the changelog fragment file in #572 to revert the removal of skippy.
I would appreciate it if you could review the PR #572
Thanks in advance.

[saito-hideki]

@Andersson007 @felixfontein @maxamillion Thanks for the review!
#572 has been merged to stable-1, so I will move forward with the release process for 1.6.1 based on stable-1 branch.

[saito-hideki]

@felixfontein @Andersson007 @Akasurde @maxamillion
Thank you all for your help. I have released 1.6.1 #574 now.

[saito-hideki]

I'm planning for the next bugfix release from stable-1
This only replaces the minimum version of Ansible Core 2.14 with 2.15. This was accidentally reverted when 1.6.1 was released, so we will fix it in 1.6.2.

• [backport][stable-1] Drop ansible-core 2.14 and set 2.15 minimum version #580
• 1.6.0 => https://github.com/ansible-collections/ansible.posix/blob/1.6.0/meta/runtime.yml#L2
• 1.6.1 => https://github.com/ansible-collections/ansible.posix/blob/1.6.1/meta/runtime.yml#L2

[saito-hideki]

ansible.posix 1.6.2 (changelog) has been released. :)

[saito-hideki]

@maxamillion @Andersson007 @Akasurde

I'm planning on releasing version 2.0.0 on December 5th.
Before that, I will create stable-2 branch next week in preparation for this.

If you have any concerns about this, please let me know.

[maxamillion]

Sounds great! shipit

[Andersson007]

@saito-hideki SGTM, how about releasing it after Ansible 11?

It'll imo allow smoother transition as Ansible 11 will not contain version 2 but people will be able to install it using ansible-galaxy, so not as many users will be affected with breaking changes and possible bugs. Then it'll get included in Ansible 12 in May.

According to the roadmap it's scheduled at 2024-11-26 and your date is fine now. The issue is that Ansible 11 depends on ansible-core and other things can occur, so I would suggest releasing it after Ansible 11 is actually out.
But it's just a suggestion:)

[felixfontein]

The Ansible 11 feature freeze was yesterday, so even if you release 2.0.0 now it won't get included in Ansible until Ansible 12.

[saito-hideki]

Hi @Andersson007 @felixfontein @maxamillion

Thanks for the comment!

The Ansible 11 feature freeze was yesterday, so even if you release 2.0.0 now it won't get included in Ansible until Ansible 12.

So, my understanding is that releasing it on December 5th is okay as originally planned. :)

[felixfontein]

Yes.

[Andersson007]

Great, no concerns then, thanks!