<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr" class="gmail_attr">On Tue, 5 Jul 2022 at 12:28, Fred Gleason via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Is there policy somewhere that states how long before the effective date of the change a release should be cut?</div></div></blockquote><div><br></div><div>There is not.  And since our effective floor is two releases per year (or one per "silly season", as it were) there's no strong reason to impose one.  I mentioned some specific examples in <a href="https://mm.icann.org/pipermail/tz/2022-July/031574.html" target="_blank">https://mm.icann.org/pipermail/tz/2022-July/031574.html</a></div><div><br></div><div>As such, one could make the case that we operate in minimal chunks of about 6 months each.  The benefit to a country for announcing a change with more than ~6 months' notice is the reasonable assurance that, even without any other urgency, the change will hit a release no later than the end of the next "silly season" after the announcement, which will tend to be between 1 and 6 months before it takes effect depending on the exact timing.  Similarly, the benefit for announcing more than ~12 months out is a release lead time of 7 to 12 months, and upward in 6-month increments.  (Now, depending on the vagaries of any given "silly season" and the exact dates things arrive and go into effect, whatever might make it into any given release one year might miss a similar release in another, but the general principle still holds.)  And the benefit for project and downstream maintainers is that none of us have to do anything special or undertake any urgent work in order to achieve those lead times.</div><div><br></div><div>Of course, the corollary which should be obvious to regular readers of this list is that if you announce changes with less than ~6 months' notice, you're guaranteed nothing.  ;)  As that describes most of our changes — typically made during the "silly seasons" themselves — they can be informally classified on a sliding scale of urgency depending on when they arrive relative to their effect.  Those a bit further out might prompt us to wait a bit to see if we can batch it with something else that comes in later, saving us all some maintenance burden, while those closer to their effective dates will tend to prompt that a release be cut more urgently (within reason).</div><div><br></div><div>In practice, readers will note that we tend to keep good tabs on when the data in the most recent release is about to "expire" and accelerate or decelerate accordingly.  Adding any arbitrary target such as "release changes 30 days ahead of effect" wouldn't help, as that would create needless artificial urgency and resultant churn on any changes that would arrive at 31 days out, while doing nothing to help those that would arrive at 29 days.</div></div><div dir="ltr"><br clear="all"><div><div dir="ltr" data-smartmail="gmail_signature">--<br>Tim Parenti</div></div></div></div>