Is there any publicly accessible source of information about current release planning? I’m not asking to be involved in the conversation, but I’d like to track when things are ready to move through alpha, beta, rc, then to release.
Specifically, I’ve been testing the new optional implementation, and I’d like to use it. I’m not sure how far into the future an rc is since it is just in alpha currently. I wonder if this is strictly internal or if there is a mailer with this information?
Hi @theherk,
We typically change the release date to fit the work being done rather than changing the work being done to fit a pre-committed release date, and so there is no currently known release date.
The way we communicate that the final release is coming is by releasing the first beta, which marks the feature freeze for the release. Once you see the first beta release, you can assume that the final release will arrive within the next month or so, depending on how significant the feedback is from the beta process.
In the meantime, I would not suggest using optional attributes for any purpose other than seeing if the feature will meet your needs and letting us know if not. So far the feedback has been positive, but that doesn’t mean that someone won’t find some opportunities to improve it in the coming alpha releases while we await some other work that’s intended to arrive in the v1.3.0 release.
Understood. I’m not suggested there should be a committed release date, just that it would be good to follow progress if such a thing were in the public view somewhere. Sounds like it isn’t; that’s fine. Thank you.
Hi @theherk,
Is some specific decision you are trying to make that would be affected by whether the final release is likely to be before or after a given date, or something similar to that?
I would be happy to give some guidance on likelihood of particular outcomes if you are able to directly ask the question whose answer depends on the release date. I can’t tell you a committed release date before there is one, but I may be able to give other kinds of advice, depending on what you are trying to decide.
Sure, I appreciate that. I have built a few modules for generating api gateway proxies. The implementation in several the stacks I manage is much cleaner with optional attributes. If I’m looking at several months before release, I won’t have time before changes have to hit production.
If there isn’t likely to be a beta before August, I will rewrite without optional attributes. If there may be, I will just hold and focus elsewhere.
Hi @theherk,
Based on what you described here, I would suggest that you move forward without using optional attributes for now, and then consider revising your modules to use optional attributes later once we reach v1.3.0 final. I would not expect beta1 to arrive during July.
Making an attribute that was formerly required into an optional one should not represent a breaking change for that module, since Terraform will treat an explicit null assigned to an optional attribute in exactly the same way as the implicit null caused by not assigning it at all.
Therefore if you write your callers with explicit null values for those not-yet-optional attributes and design your modules to handle that (e.g. by using the coalesce function for now to provide any default values) you should be able to later change the modules to use optional attributes instead while leaving the callers unchanged, and then at your convenience you can remove the explicit null attributes from the callers so they will begin to rely on the optional attributes behavior.
Sounds like a plan. Thank you, as always, for the support.