18:00:22 #startmeeting Community Working Group 18:00:22 Meeting started Wed May 27 18:00:22 2020 UTC. 18:00:22 This meeting is logged and archived in a public location. 18:00:22 The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:22 The meeting name has been set to 'community_working_group' 18:00:28 #chair felixfontein 18:00:28 Current chairs: felixfontein gundalow 18:00:38 cyberpear gregdek 18:00:45 o/ 18:00:46 #info Agenda https://github.com/ansible/community/issues/539 18:00:53 cyberpear: hi there :) 18:01:09 * cyberpear can't believe it's already Wednesday! 18:01:11 * gregdek hullos 18:01:11 welcome everyone to the first community working group meeting :) 18:01:20 I am sadly double booked, but I will lurk :) 18:01:36 * acozine waves 18:02:43 #chair cyberpear gregdek acozine 18:02:43 Current chairs: acozine cyberpear felixfontein gregdek gundalow 18:02:59 I put two topics on the agenda, but in the end it's all about community.general and community.network versioning and releasing (and deprecation) 18:03:18 #info Thanks for joining the first of the new series of Community Meetings 18:03:57 \o/ 18:04:00 #topic Community.(general,networking) versioning, releasing and deprecation 18:04:08 * samccann waves 18:04:28 #chair samccann 18:04:28 Current chairs: acozine cyberpear felixfontein gregdek gundalow samccann 18:04:30 because sooner or later we have to release 1.0.0, and maybe some more complete versions before, and so we have to know how to adjust all the existing deprecation version numbers ;) 18:04:30 hi samccann :) 18:04:39 hello everyone! 18:05:08 (and things like having a changelog) 18:05:17 Hi 18:05:28 #info felixfontein's proposal for Versioning, deprecation and changelogs for community.general and community.network https://gist.github.com/felixfontein/2bad8517b70008ab9be90387ee4090c8 18:05:31 #chair abadger1999 18:05:31 Current chairs: abadger1999 acozine cyberpear felixfontein gregdek gundalow samccann 18:05:34 hi abadger1999 :) 18:06:36 To cut to the chase: is there anything in the proposal that people disagree with? 18:06:38 after some discussions I tihnk the first question would be: how often do we actually want to release new features? and how hard do we want to try to adhere to semantic versioning? 18:06:47 andersson007_: I see you've added a lot of comments already, thank you 18:07:08 I'd suggest major versions "as needed", unless there's a good reason for 6 months? -- or maybe "no more often than 6 months" 18:07:43 I suspect that "major" releases will largely be driven by changes to ansible-base that require major changes. 18:07:45 cyberpear: the 6 months is mainly so that deprecation versions can be picked from the schedule (i.e. remove in 4 major versions after deprecation) 18:07:48 cyberpear: fair question. 18:07:58 but that depends on whether we actually want to deprecate by version 18:08:08 felixfontein: Just to clarify, do you think this is specific to c.general and c.network which have a lot of commits? 18:08:22 And those kinds of big dependency changes to ansible-base shouldn't come more frequently than 6 months, I shouldn't think. 18:08:29 or maybe "new major version to correspond with ansible-base releases, if required" 18:08:32 (I know it says that in the proposal title, just want to make sure everybody is on the same page) 18:08:37 nitzmahone and jborean93 yesterday pointed out that deprecate by version has some disadvantages, mainly that if you have to do an unexpected major release, you speed up removal if you don't adjust all deprecation versions 18:09:12 gundalow: some of the structure in there is probably only needed for large "incoherent" collections like c.g and c.n 18:09:43 gundalow: smaller collections don't have a huge amount of independent parts which independently want to add/deprecate/remove features and make releases 18:09:48 I know abadger1999 strongly favors version deprecation -- it's my hope that we can sync release cycles strongly enough that the two are usually equivalent, a la Fedora's mostly 6 month cycle 18:09:58 `New features can be backported to the current stable-x release branch after x.0.0 and until x.5.0 has been released` I'm not sure about that, haven'tgot my head around the implications of that 18:10:05 But we should probably be updating c.g more often than that 18:10:16 gundalow: essentially that means that new features can go into the current major version 18:10:20 felixfontein: is your aim with ^, so that people don't have to wait 6 months for new features? 18:10:34 fwiw I think the ansible-maintained collections will use a timeline based deprecation cycle, not version 18:10:43 So maybe we say "major releases are by definition once every six months and that's when deprecations take place" and we're rolling minor releases with content changes more frequently... 18:10:49 so while 2.2.0 is the current release, it gets new features. when 2.5.0 is released, the next release will be 3.0.0, so no new features for 2.x.y with x>5 anymore 18:10:52 w/ semver, you can have new features in a Y release; you just can't break old stuff w/o bumping X 18:11:02 Right 18:11:06 gundalow: yes. my idea was that new features once per month is probably a good schedule 18:11:12 but that's something we maybe also have to discuss 18:11:14 And just because you bump X, it doesn't follow that you must break old stuff :) 18:11:24 It's just the only opportunity to do so 18:11:25 gregdek: indeed! 18:11:26 felixfontein: in that case, you'd switch to doing only Z releases after X.5.0 18:11:36 This looks sane.... provided there's the manpower and leadership to do it. 18:11:45 cyberpear: exactly. so x.5.1, x.5.2, ... x.5.1231 will be the next releases 18:11:48 gregdek: if you're not breaking old stuff, please don't unnecessarily bump X 18:12:03 2 years of support and releases approximately every month. 18:12:26 abadger1999: I would only do monthly releases of the current major version, and maybe the previous one (if there are bugfix backports) 18:12:29 i think it will end up being 4 concurrent releases at a time? 18:12:35 felixfontein: To throw a random thought out. If we don't backport features, what about doing major releases two (or three) months, would that reduce the amount of branches we need to maintain, and dramatically drop the amount of backports needed? 18:12:51 the two before should hopefully almost never get updates (only in case of major bugs or security bugs) 18:13:00 * gregdek goes to the other meeting he's in, sorry 18:13:05 gundalow: that would 18:13:07 (sigh) 18:13:45 gundalow: it has a big disadvantage though: since ACD sticks to one major version of the collection per release cycle, there will be no new features after 3 months since the collection has a new major version 18:14:15 w/ semver, features go into Y releases; breaking changes go into X releases. fixes go into Z releases; so if we don't want to backport features, we'll only ever have X.0.Z releases 18:14:19 so the release cycle of c.g/c.n should be roughly similar to the one of ACD, and that somewhat similar (or related to) the one of ansible-base 18:14:31 am I correct to think that the proposed cadence would respect the "negative" aspects of semver (e.g. don't break stuff except when you bump X), but not the "positive" aspects (some major versions might not add anything huge)? 18:14:53 gundalow: also, if we have major releases every few months, people will be not happy to upgrade, since new major version = you have to check everyplace the collection is used if something breaks 18:15:36 if we're doing semver, let's do it consistently... if we never backport features, let's never have an X.1.0 release; only X.0.Z 18:15:46 acozine: I think so 18:15:46 felixfontein: yup ,that's a fair point 18:15:52 bumping Y implies adding features 18:16:00 so IMO there should be regular major releases, but not too often 18:16:07 I assume the ship has sailed on whether to use semver at all 18:16:21 cyberpear: semver is kind of dictated by galaxy I think 18:16:28 I'm not against it; just do it right if you do 18:16:45 you can still do a Y version bump without new features. it's maybe strange, but possible I think :) 18:16:52 and in a semver world, you can opt-out by having 0.Y.Z, and you're off the hook 18:16:58 I like the idea of a time-based cadence 18:17:19 one problem with semver is that backporting new features makes it possible to accidentally do breaking changes in minor versions. (but that's also possible with bugfixes.) 18:17:20 so we can be even-handed in saying "if you want your feature in X.Y, it needs to be merged by this date" 18:17:47 acozine: yes, that would be fine 18:17:59 felixfontein: why would you want to bump Y w/o adding a feature? why not just bump Z? 18:18:10 acozine: that's one reason why I like having an explicit list of dates, so everyone can plan accordingly. especially important for a large collection like community.general, where a lot of different independent groups work on independent modules 18:18:42 cyberpear: mainly to keep the schedule :) so RM doesn't have to check every release "is there really a new feature in here?" 18:18:47 with this approach the changelog/porting guide becomes more important, since folks might skip a few versions when upgrading 18:19:14 I personally like Ubuntu's YYMM style 18:19:20 cyberpear: for small collections skipping versions is feasible, but for large ones either someone has a lot of spare time, or someone has to be paid :) 18:19:36 gundalow: link? 18:19:38 gundalow: me too. 18:19:38 felixfontein: skipping? 18:20:17 oh, I never connected Ubuntu 16 with the year 2016 18:20:19 d'oh 18:20:23 cyberpear: if we announce 3.5.0 will be release on say August 27th, but on August 27th we notice that we ahve no new features, so we should use 3.4.1 instead, it kind of breaks the schedule 18:20:47 acozine: it took me some time to realize this as well :) but once you get used to it, it is *really* nice :) 18:21:04 yeah, that is really nice 18:21:22 so only announce 3.5.0 if there have been any new features? 18:21:43 agreed YYMM versioning is useful, but it's not semver 18:21:49 cyberpear: doesn't work well if you want to publish a date->version table a long time in advance :) 18:22:20 cyberpear: it's definitely not semver, but it's a totally different option that might work well for collections 18:22:56 acozine: I think it's worth discussing, especially if we don't really want to do semver anyway 18:23:04 except that to make galaxy happy, you need to use 2004.0.0 instead of 2004 ;) 18:23:22 I think semver is kind of baked into ACD 18:23:28 oh, please no 18:23:37 because without semver it is kind of impossible to synchronize such a large zoo of collections into a unified release 18:23:41 yes, it technically works 18:24:15 but probably need to bring in the galaxy folks if they've got semver hardcoded and we actually want to go non-semver 18:24:16 I mean, how do you want to relesae a new ACD version which doesn't break backwards compatibility if you have to check every of the 50+ collections manually? 18:24:27 We need the semantics of semver to glue things together, but the strict meanings of x.y.z we're probably less bound to... 18:24:30 can we have date-related release numbers on individual collections and semver on the overall ACD version? 18:24:33 does someone actually wants to avoid semver? 18:24:38 Yes, ACD itself as a collection of collections will probably need something like semver 18:24:39 (I don't) 18:25:01 AFAIK collections today MUST be semver 18:25:06 Hmm... things like publishing release data (3.0 will come out on Aug 27, 2021) is also something that hinges on my manpower question. 18:25:07 Yes, that's correct 18:25:22 ah, okay 18:25:45 abadger1999: in particular the 27th of december dates will be funny :) 18:26:28 it might be better to have a somewhat more flexible schedule, and only fix more concrete dates some time before the release 18:28:40 we don't announce dates for ansible itslef 18:28:48 "guide dates, subject to change" 18:29:00 (or we do a poor job... freeze is nominally Saturday, IIRC) 18:29:41 gundalow: or just specify a month for everything that's further than 2-3 months away 18:29:53 I'm happy for Ansible (ACD) to have dates that can change. This is a community project, with community resource. 18:29:57 3.0.0 will be released in august 2021 18:31:12 Ok, what do people think the next steps are? 18:31:28 or the specific questions that need answering? 18:31:49 I think we should vote (maybe just tentatively, to get an idea what people want) on a few more specific things 18:31:56 +1 18:32:07 yup, sounds good 18:32:23 felixfontein: got any specific questions in mind? 18:32:26 like 1) semver vs. other versioning? 2) how often new features, how often breaking changes (i.e. major releaes for semver)? 18:32:28 gundalow: about comments, yep. i'm taking part in an unplanned release at my day work now, so can't be actively involved here 18:32:48 more questions depend a bit on the answers to these two :) 18:32:52 andersson007_: don't worry about it you've been doing lots of great stuff 18:33:13 gundalow: andersson007_: indeed! 18:33:29 gundalow: felixfontein: thanks:) 18:33:39 I think moving away from semver for collections is a wider discussion, and I'm concerned that it might not go anywhere 18:33:40 so. does someone prefer something other than semver? 18:34:23 gundalow: I agree, I mainly want to know if someone currently prefers to not use semver, or if everyone would be happy with semver 18:34:47 QUESTION: Anyone interested in non-semver for collections 18:35:14 semver for collections will mean that constructing ACD/ansible gets harder. 18:35:32 abadger1999: do you mean '*not* semver'? 18:35:41 felixfontein: yes, sorry. 18:35:57 ok :) I fully agree then 18:36:05 semver for collections means that you bump the X or Y if an X or Y of an included collection was bumped 18:36:20 If collections do not use semver, constructing ACD/ansible will require collection owners tell the ansible builder which versions to include for every major and minor release. 18:36:21 *bump ACD if an included colleciton was bumped 18:36:25 I think that non-semver for collections is off the table. 18:36:39 And maybe we should agree that here, even if everyone doesn't love it. 18:36:40 It's possible (Give me a version range and I can manually stuff it in the file). 18:36:50 But it requires more human interaction. 18:37:08 I'd only ask that if we're doing semver, we do it right. 18:37:32 is ACD itself semver? 18:38:11 ok, so some terminology 18:38:31 if ACD wants to use the same version numbers as ansible-base, it cannot be semver 18:38:39 if semver for ACD itself, it seems reasonable that every release will have some deprecated items removed, hence a major version bump; otherwise, point releases could be Y releases if new features are allowed, or Z releases if features are not allowed 18:38:41 ansible-base = gh/ansible/ansible 18:38:55 https://github.com/ansible/community/issues/539#issuecomment-634846106 18:38:59 ansible 2.10 will be `ansible-base` + subset of collections 18:39:36 so the `ansible` package will continue the non-semver Ansible versioning format 18:39:45 Maybe that will change in 3.0, unsure 18:39:49 Errrr.... 18:39:58 abadger1999: did I get that wrong? 18:39:59 gundalow: that would be 3.0.0 then ;) 18:40:11 felixfontein: ah, yes 18:40:13 ansible-base will definitely continue non-semver versioning for now. 18:40:20 abadger1999: +1 18:40:21 will 2.10.1 only contain bugfixes, or also new features (compared to 2.10.0)? 18:40:26 ACD/ansible we can control our own dstiny. 18:40:31 I think switching to semver for ansible itself should be a much larger discussions 18:40:50 The release schedules of ansible-base and ansible are going to get out of sync fairly rapidly, it looks like. 18:41:08 I guess for the first ACD releases, sticking to the ansible version numbering system is helpful to avoid too much confusion of users 18:41:13 So after 2.10, we probably are not bound to their versioning. 18:41:45 I'd suggest to match ACD to ansible version, to avoid confusion 18:41:49 Should ansible be semver? I don't know... I just wanted to be clear that we are not going to match with ansible-.base for very long. 18:42:26 I think nobody really wants to start changing versioning for 2.10. so maybe let's dicsuss this once 2.10 has been released :) 18:42:31 (or 2.10.0) 18:43:09 felixfontein: yeah.... all of your points are good. For your question... I currently have it coded to allow new features into 2.10.1. But it's an easy change to make it bugfixes only. 18:43:15 I wonder if we are ending up in stuff that's way to far in the future 18:43:28 That's a question for you all of "What do you want?" 18:43:50 ok. so I think the following is consensus: use semver for collections, in particular community.general and community.network; use old versioning schema at least for 2.10, and discuss a new versioning schema for ACD later? 18:43:55 I think ACD should allow new features in 2.10.X releases, but not breaking changes 18:43:58 Some clarity here: ACD *is* Ansible. 18:44:02 ^^^^^ 18:44:05 ansible-base is a separate project. 18:44:10 felixfontein: +1 I wholheartedly agree to all of that. 18:44:12 We are highly dependent on one another. 18:44:19 gregdek: I use ACD to make it clear I really don't mean ansible-base :) 18:44:42 Fair, but never use ansible when you intend to say ansible-base. 18:45:00 cyberpear: Cool. 18:45:02 gregdek: I hope I avoided that so far 18:45:07 felixfontein: I'm a solid +1 to what you said 18:45:26 QUESTION: Anyone against `use semver for collections, in particular community.general and community.network; use old versioning schema at least for 2.10, and discuss a new versioning schema for ACD later?` 18:45:46 (if you're against it, write a quick 'no' before writing a longer explanation :) ) 18:45:47 LGTM 18:45:50 Was more for cyberbear and his comment "I'd suggest to match ACD to ansible version, to avoid confusion" to be clear 18:46:34 yes, ACD version to ansible-base version 18:46:35 cyberpear: the first release of ansible (the package formally known as ACD) will be `2.10`, which will depend on `ansible-base@2.10 18:46:43 ` 18:47:12 so next questions from my side would be 2) how often new features (minor release) and breaking changes (major releases), 3) date vs. version based deprecation? 18:47:41 To step back a bit, what do we think users want/care about? 18:48:15 At least as fast as ansible <2.10 releases 18:48:19 ie, 6 months 18:48:21 felixfontein: what you suggested in your gist proposal sounds good to me. we discussed 18:48:32 it looks to me that a) users want new features more often, b) users want stability (i.e. avoid breaking changes) 18:48:43 or is their a strong need for people to get new features more frequently 18:49:03 * gundalow agrees with a & b 18:49:12 especially people who contributed new features do ask when they will get released 18:49:15 I think new features should come faster, perhaps monthly; breaking changes should only happen when ansible-base bumps its "major" version; e.g., 2.11 from 2.10 18:49:28 I feel like developers have wanted to get features out faster than traditional ansible (6 months) 18:49:31 felixfontein: clarification question: for ansible/acd or for community.*? 18:49:43 samccann: yup, I'd agree 18:49:44 cyberpear: the ansible-base cycle might slow down, possibly even to yearly "major" releases 18:49:57 then you actually get a story for how end users tangibly benefit from collections 18:50:27 seems fine w/ me; I guess we could revisit if it become a problem 18:50:48 abadger1999: I guess mainly for collections; but they also wanted to have that for ansible in the past, so probably also for ACD - I guess the question is how many users will use ACD, and how many users will use ansible-base and just install the collections they care about 18:51:21 ACD will become like EPEL, shunned by InfoSec departments 18:51:23 I know it's good to think about all the future implications, so we don't paint ourselfs into a corner. Though part of me feels we need to get 2.10 out there and get some real feedback 18:51:30 so folks will choose the collections they actually need 18:51:35 felixfontein: I thought someone somewhere said they expect most users to use ansible (aka acd) but I don't have anything to back that up 18:52:35 samccann: I heard different things from different people; I guess it is really hard to find out until 2.10 is out and we can see what people do 18:52:39 once ansible-base is a thing, I think lots of folks will try to depend on only that, to avoid dependency bloat; but probably end users will use ACD for convenience for quite some time 18:52:45 gundalow: I agree 18:53:55 does anyone think that new features every 6 months is enough? 18:54:25 for a collection or for ansible ? 18:54:37 I guess features every 6, 3, 2 or 1 months are good choices (good old divisors of 6 ;) ) 18:54:44 it's "enough" in that it matches the status quo, but doesn't give users a "benefit" of collections 18:54:49 cyberpear: +1 18:54:51 samccann: both 18:54:56 (kind of) 18:55:04 cyberpear: +1 18:55:11 collections imo need to move faster than 6 months for new features 18:55:15 I'd prefer new features more often. 6 months really is a long time. 18:55:18 would quarterly releases take the per-release pressure off? 18:55:38 (quarterly == every 3 months) 18:55:41 If the versions don't contain dates, then can we start slow then ramp up release cadence 18:56:05 acozine: if releasing is sufficiently automated, I assume we could even release more frequently. but then, I don't have much experience with releasing such big beasts 18:56:05 yeah thinking individual collection owners will make their own decisions on cadence 18:56:29 I'm personally not as concerned about dedicated collections 18:56:51 felixfontein: that makes sense, I just don't want to make promises we can't keep 18:56:53 as they, as you say, can do their own thing, and have a good understanding of most of the changes 18:57:45 so here's a scenario I've heard - community.network as a 'breeding ground' for new ideas (aka modules). As it gains acceptance, works out the kinks, etc... that module could be 'graduated' to a more specific collection (even a supported one at some point). A slow cadence for community.network of every 6 months makes that graduation problematic/slow 18:57:47 "c.general and c.network will initially have major releases quarterly. This may change in the future 18:58:00 " 18:58:17 gundalow: I really would prefer major relases less frequently 18:58:26 me either 18:58:47 a major release means that you have to look at all uses of that collections (which could be really a lot for large collections such as c.g and c.n) 18:58:55 felixfontein andersson007_: you feel going from 6 months to 3 months for major releases is too frequent? 18:59:17 gundalow: I think it is 18:59:22 yep, looks too frequent 18:59:25 gundalow: why do you want major releases that often? 18:59:32 losing the plot here - does a new module qualify as a major release or a minor release for a collection? 18:59:35 I'm just throwing stuff out there 18:59:40 how about every ACD release is a feature release. Included collections can choose their own policy, but we won't take breaking changes -- make breaking changes only coincident w/ ansible-base releases 18:59:44 samccann: new module = new feature = can appear in minor version 18:59:58 ok thanks felixfontien 19:00:03 switch acd to rolling releases .. then the numbering is simplified 19:00:22 samccann: so I believe the change is that semver is (partly) about knowing if a upgrade could break you 19:00:38 adding new functionality (new module) doesn't break anyone 19:00:57 ok so major release here means breaking change within the collection 19:01:00 major releases are only ones w/ breaking changes, such as deprecated feature removal 19:01:05 Though adding new module, refactoring module_utils and changing some default options could break people 19:01:26 * acozine has to go pick up her cat from the vet 19:01:33 gundalow: every change can potentially break :) 19:01:36 heh 19:01:49 we have a changelog fragment type for that now! 19:01:53 normally 'new feature' is considered a bump cause of new 'possible inestablity' .. but new plugins should be discrete enough to avoid that 19:01:54 (just an aside) 19:02:14 samccann: true :) 19:02:54 POLL: every how many months do you like to have major releases (with breaking changes) for collections? just write the number 19:03:07 8 19:03:18 (only if coincident w/ ansible-base release) 19:03:39 I mean for collections, not for ACD 19:03:40 felixfontein: definitely no less than every 6 months 19:03:48 for collections 19:03:48 given gundalow's comment on minor changes potentially being breaking fixes, 6 19:03:58 (for those large collections) 19:03:59 included collections can make their own cycles, but ACD will only take breaking changes at a stated frequency 19:04:05 6m - 1 year 19:04:11 Can someone put this meeting on the calendar for next time? 19:04:11 6m 19:04:13 6 19:04:47 * samccann ponders if there is some deepseated psychological comfort factor about the number 6 now 19:04:55 :D 19:04:56 ok, 6 is ok 19:05:07 so nobody wants less than 6, it seems 19:05:25 (or nobody bothered to mention it if they do) 19:05:48 no, my earlier noise about faster than 6 was my misunderstanding about where a new module would fit in (minor version I learned) 19:06:21 hence my initial "no more frequently than 6 months for breaking changes" 19:06:48 #action Setup this meeting https://github.com/ansible/community/blob/master/WORKING-GROUPS.md#process-for-ansible-staff 19:06:57 ok. so 6 it seems to be? (for collections at least) 19:07:38 POLL: how often do you like to have new features? just write the number as in "every n months" 19:07:41 (agreed 6 month major release for community.general and community.network. This maybe revisited in the future) 19:07:50 is ^ a fair summary, any more detail I need to add 19:08:02 gundalow: I think it is a fair summary 19:08:06 gundalow: +1 19:08:12 +1 19:08:19 I prefer new features every 1-2 months 19:08:28 #agreed 6 month major release for community.general and community.network. Other collections can release at their own cadence. This maybe revisited in the future. 19:08:30 Thanks 19:08:40 1 19:08:47 ------------------ 19:08:49 POLL: how often do you like to have new features? just write the number as in "every n months" 19:08:50 every month for new featurs 19:08:56 1 or 2 19:09:03 1-2 19:09:08 * samccann she sez not doing any of the work involved 19:09:10 we could start from 2 19:09:21 yeah that's a good idea 19:09:30 1 19:09:37 start at 2 months, bring it in if needed and if the community has bandwidth to make that happen 19:09:43 (not more frequently than monthly; otherwise, only as-needed) 19:09:51 samccann: +1 19:09:52 2+ 19:10:17 cyberpear: would you be OK with 2 months? You appear to be the only person saying `1` 19:10:18 we could start from 2, then will see 19:10:26 Just want to make sure we aren't missing something 19:10:28 sure 19:10:33 abadger1999: are you also ok with 2? 19:10:43 abadger1999: I assume your '1' was for this as well 19:10:53 I say 1 as well, but 2 is fine 19:11:26 Just don't guarantee the release schedule out too far and we can change it as we learn more :-) 19:11:27 I say "not more frequently than 1 month" but only do feature releases if there are features that need releasing 19:11:56 abadger1999: I think the schedule is mostly important for major releases, and doesn't have to be up to a day ;) 19:12:35 so... maybe last question for today... do you prefer deprecation by date, or deprecation by version? 19:13:14 (for ACD, I think it's fine to assume every 2.10.X release might be a feature release) 19:13:23 if we have major releases every 6 months with a relatively fix schedule, i.e. the exact date might vary a bit, but it will always be in the defined month, both are relatively equivalent 19:13:58 By version. 19:14:00 felixfontein: deprecation by version 19:14:09 Proposing: (#agreed New features for community.general and community.network will be released ~2 months. We will not guarantee how many major releases we do at this cadence yet. We need to get some feedback from users, contributors and maintainers to see how much work it actually is ) 19:14:23 By date isn't very good for end users 19:14:23 Feedback on ^^^, please keep me honest here 19:14:29 gundalow: do you mean 19:14:34 "minor" or "major"? 19:14:36 (sorry for newline) 19:14:40 for collections where major versions are only bumped along with ansible-base version, I think by version definitely 19:14:50 i can say the ansible-maintained collections have decided to deprecate by date, not version 19:15:02 whether that matters for community collections... ? dunno 19:15:24 (by ansible-maintained I mean the internal developer team at Ansible/RH and the collections they own) 19:15:32 samccann: I think that's fine as long as they match the major versions to those dates 19:15:54 the trouble with by version is you can't guarantee that you will stick to a cadence that the deprecation period mandates 19:15:58 cyberpear: deprecation by date would be "removed in the next major release after 20xx-yy-zz" (for collections) 19:16:07 the 'dates' is also a automation hub issue 19:16:18 ^^ yes; as long as that's what they adhere to, it's probably fine 19:16:25 what happens when you need to bump the major version outside of the proposed 6 month time frame 19:16:51 felixfontein: are we still taking specifically about community.general and community.network, therefore Automation Hub (where *S*upported content goes) is out of scope? 19:16:52 but it does not work the same, they select a 'specific version' and that is supported for the range, deprecations/versioning is parallel to that 19:16:53 now you either have features that are removed before the full 2 years, or the dep date needs to be updated for stuff that was going to be removed in that version 19:17:03 jborean93: I was wondering a bit in which situations we actually have to do that 19:17:23 gundalow: IMO yes 19:17:36 also wondering why might need to bump major out of cycle 19:17:45 It's more about keeping your options open 19:18:09 cyberpear: ansible-base decides on a 3.0 release 2 months after you released acd 19:18:09 or if you want to adjust the cadence at some point in the future 19:18:15 maybe for a "breaking security fix", you just violate semver guarantees 19:18:24 or if there's a feature in ansible-base that you need for the collection out of cycle 19:18:35 By date is an end user nightmare at the moment, though. 19:18:41 I disagree 19:18:49 Tooling can address some of that but not all 19:18:51 it states a date in which this feature cannot guarantee to be there 19:18:53 i also think 'by date' is not something people will handle well 19:18:57 agreed; if I install a particular version of ACD, I don't want it to self-destruct by date 19:19:02 (I know that's not implemnted) 19:19:09 but it won't self-destruct 19:19:18 but I don't want the tooling to tell me "this is doprecated" just because a date passed 19:19:23 it will still require a new release for something to pick up the breaking change 19:19:28 jborean93: but by setting a date, that is impresison most will get 19:19:30 but yesterday it didn't tell me that, but I didn't make any system changes 19:19:37 But the date doesn't help you install and update things at the moment 19:19:39 bcoca: that's why the wording is important 19:20:08 You need both the date and the versions that go along with those dates and then you can feed the versions to the tools 19:20:11 jborean93: wording or not, getting a deprecation w/o having 'done anything' is also something most users will find 'undesirable' 19:20:11 cyberpear: the dep won't appear based on the date, the dep appears if you use a deprecated feature and that tells you when you can't rely on it being there in the future 19:20:14 cyberpear: it would always tell you "this feature will be removed in a release after 2020-05-xx", no matter whether that's a date in the past or future 19:20:35 bcoca: they will have done something, they use a deprecated feature just like it happens today with by version 19:20:46 exactly 19:20:52 abadger1999: you also need to know to which collection the date is refering ;) 19:21:13 hence why the wording is important 19:21:49 I'm not saying dep by version isn't right, just giving you the reasons why most of the S*upported collections are using by date 19:22:04 it looks like runtime.yml supports both scenarios anyway 19:22:25 I'll tell you on the RHEL 8 side, the deprecation by date is very confusing/annoying 19:22:44 I personally find version numbers easier to handle than dates. for dates, I have to figure out whether the major release of a version was relesaed before or after this date. for a version, I just compare versions 19:23:22 jborean93: if this is going by AH rules .. it really should not affect 'releases not specifically flagged as supported' 19:23:30 you can handle deprecations independantly 19:23:38 bcoca; no idea what you mean by that 19:23:43 saying version X.Y is EOL on "this date" is much clearer 19:23:59 cyberpear: versions have a support period 19:24:05 sorry, AH? 19:24:06 that is independent from deprecating features 19:24:09 the date issue started becasue of how the AH wording on support was 'confusing' .. it does not mean a 'module will be supported till certain date' 19:24:10 automation hub 19:24:15 community doesn't sell support, so we are more free :) 19:24:30 so on AH, there is a 24 month maintainance release 19:24:33 but that a 'release' is supported till certain date and for THAT release (minor increments) you cannot deprecate anything 19:24:44