19:01:43 <bcoca> #startmeeting ansible core public irc meeting
19:01:43 <zodbot> Meeting started Tue May 26 19:01:43 2020 UTC.
19:01:43 <zodbot> This meeting is logged and archived in a public location.
19:01:43 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:43 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
19:01:59 <bcoca> #topic https://github.com/ansible/proposals/issues/178
19:05:28 <felixfontein> so
19:05:33 <felixfontein> sorry, my wlan was a bit unstable
19:05:50 <felixfontein> the proposal is about making version numbers work better with collections
19:06:24 <felixfontein> this is both for genreated documentation (html or ansible-doc), and about deprecation version numbers displayed during runtime (feature will be removed in version x.y.z)
19:07:03 <felixfontein> the problem is that due to shared code and doc fragments, these version numbers must not have any connection to the module (or plugin) currently being run
19:08:58 <cyberpear> seems like a very good problem to solve to reduce confusion
19:09:11 <felixfontein> I think so too :)
19:09:30 <felixfontein> for version_added and deprecation of plugin options and deprecation of modules, Ansible knows where the version number belongs to
19:09:49 <bcoca> the problem already existed, but only affected plugins distributed via roles
19:10:00 <felixfontein> for deprecations in code (which are all feature deprecations for modules, since argument spec is constructed by code) Ansible cannot know without a lot of 'magic'
19:10:03 <felixfontein> true
19:10:21 <felixfontein> but now we have collections, and code shared between collections, and between collections and ansible-base
19:10:40 <felixfontein> like all the modules using the `files` doc fragment and the AnsibleModule constructor flag
19:11:00 <bcoca> worse, the ones using the fragment w/o the constructor
19:11:08 <felixfontein> true.
19:11:15 <felixfontein> these are probably beyond all hope though
19:11:31 <felixfontein> my aim is to at least try to solve this in the cases where it is possible to solve it with a reasonable amount of work
19:12:20 <felixfontein> I've tried to write this down in the proposal: automated version source tracking where possible (i.e. in doc fragments and YAML doc strings), and explicit tagging where it is not possible (i.e. in code)
19:14:09 <felixfontein> I've also prepared a PR which implements this for ansible-base
19:14:20 <felixfontein> https://github.com/ansible/ansible/pull/69680
19:14:42 <felixfontein> which now needs a little update after the routing PR got merged :)
19:16:04 <felixfontein> so.. any opinions on this? :)
19:16:35 <bcoca> s/ansible-base/ansible/ ... since that will also affect adjacent/roles display
19:16:44 <bcoca> and it wont really be 'true'
19:17:51 <jborean93> felix: slightly off topic but has that dep by date PR been merged yet?
19:18:10 <felixfontein> jborean93: no, nobody has reviewed it for quite some time now
19:19:14 <jborean93> darn, will need to look into that quickly, do you have a link for that?
19:19:41 <felixfontein> https://github.com/ansible/ansible/pull/68177
19:20:00 <jborean93> thanks
19:20:03 <felixfontein> jborean93: could you please re-trigger CI first, I hope they still work with the routing PR merged, but who knows :)
19:20:33 <jborean93> sure
19:27:37 <felixfontein> bcoca: what would you change?
19:29:23 <bcoca> ^ said already
19:30:12 <felixfontein> do you mean that deprecation versions in version_added and doc fragments in library/ will be treated as being part of ansible-base?
19:31:18 <felixfontein> otherwise I'm not sure what you mean
19:33:48 <bcoca> basically, also roles
19:34:07 <bcoca> why more generic 'ansible' might be better in that state
19:34:37 <felixfontein> where are role versions shown in ansible?
19:34:58 <bcoca> they aren't .. been proposing those for years ...
19:36:34 <sdoran> In general, I like this approach. I would maybe nitpick over `ansible.builtin` in favor of `anisble-base` or just `ansible` for deprecations that relate to core code and modules included with `ansible-base`.
19:37:29 <sdoran> The error message may read a bit better if it is "deprecated in ansible:2.11".
19:37:52 <sdoran> I'm still wading back into this after being gone for a few months...
19:38:24 <sdoran> Role versions are displayed by `ansible-galaxy role list` but only if there is a `/meta/.galaxy_install_info` file that contains the version information.
19:38:37 <sdoran> It's not nearly as defined/enforced as collection version information.
19:38:39 <felixfontein> sdoran: I've been pondering about that as well :) I finally decided for ansible.builtin since it is also a collection name
19:39:11 <felixfontein> currently the error message will be `will be removed in Ansible-base 2.11`
19:39:34 <sdoran> Ok.
19:39:47 <felixfontein> see https://github.com/ansible/ansible/pull/69680/files#diff-b433171851ee6e9ab6c4f98f233678b5L260
19:40:20 <felixfontein> it's only in ansible-doc right now that the short notation is used (`version_added: ansible.builtin:2.10`)
19:40:43 <sdoran> Ok. I've been looking through that PR and there's a lot going on. :)
19:40:50 <felixfontein> there definitely is!
19:41:53 <felixfontein> I have to adjust one (hopefully) part (in cli/doc.py) so that it works with the routing PR
19:42:32 <bcoca> i just started writing that part for listing
19:42:37 <bcoca> also , routing was renamed
19:42:44 <bcoca> ansible_builtin_runtime ....
19:42:55 <sdoran> I suppose I am mostly in favor of this approach.
19:43:24 <sdoran> But I haven't been deep in the weeds of collections like others, so I wouldn't put a ton of weight of my vote at this point.
19:43:43 <felixfontein> bcoca: true, but the PR was called 'routing PR' by most people :)
19:43:56 <felixfontein> in collections its meta/runtime.yml now
19:45:19 <bcoca> also it was called tombstoning by most people for months before that, but  .. moving on
19:45:23 <felixfontein> true :)
19:50:30 <felixfontein> does nobody else have an opinion on the proposal (or PR)?
19:50:55 <bcoca> they probalby wont till after it is merged ...
19:53:32 <felixfontein> the main change for collection authors this PR adds is that deprecation versions have to be adjusted. though most of them (at least in community.general and community.network) have to be adjusted anyway
20:03:43 <felixfontein> so...
20:04:03 <felixfontein> IMO the change for deprecation versions only really makes sense if it is merged before the freeze
20:04:09 <felixfontein> is there any chance for this?
20:04:14 <bcoca> idk
20:04:42 <felixfontein> I think it would really make 2.10 more complete if version references would make more sense
20:06:12 <nitzmahone> felixfontein: I'd agree on both counts
20:10:01 <bcoca> k, we are already over time, so going to close this now, but think more people should really read up and get a vote on it
20:10:04 <bcoca> #endmeeting