Add a policy for migration of algorithms to the legacy provider #67
Conversation
nhorman
requested review from
levitte,
arapov,
hlandau,
t8m,
t-j-h and
mattcaswell
policies/legacy-migration.md
Outdated
|
|
||
| ## Migration announcement mechanism | ||
| Announcements of migrations from a source provider to the Legacy provider is | ||
| made via the ALG-DEPRECATIONS.md file in the source code root directory for |
There was a problem hiding this comment.
This is an interesting idea to list the deprecations. Perhaps we should not confine this just to algorithms but to other things deprecated from now on?
There was a problem hiding this comment.
I'm fine with expanding a deprecation list, sure. Maybe rename the file to DEPRECATIONS.md, and have a section for legacy migrations, as well as sections for any other distinct deprecation in the future?
|
ping @openssl/committers still looking for input/reviews here |
| semantically versioned minor release (see announcement mechanism below). | ||
|
|
||
| 3) Coincidental to the announcement above, the algorithm in question may be made | ||
| available in both the source provider and the legacy provider. |
There was a problem hiding this comment.
source provider? Did you mean default provider?
There was a problem hiding this comment.
I used the term source, as I didn't want to constrain deprecation to only the default provider. i.e. if we ever want to deprecate algorithms in the fips provider, or if we create say a pq provider in the future, this same process might be useable.
|
|
||
| ## Migration announcement mechanism | ||
| Announcements of migrations from the default provider to the Legacy provider is | ||
| made via the DEPRECATIONS.md file in the source code root directory for |
There was a problem hiding this comment.
How is the announcement of a deprecation made, and how is feedback received?
History:
At one stage the RIPE digest was moved to the legacy provider. It was then added back into the default provider after it was found that BITCOIN programmers were not happy that it had been moved.
|
@slontis I was working under the assumption that DEPRECATIONS.md would be the canonical source for an announcement, and that it would be the responsibility of interested parties to review that file regularly and raise issues if/when a given deprecation wasn't appropriate. Given that we follow the 'at least one release prior' process to do the announcement before the actual removal, this (at least to me) provides sufficient warning to make community voices heard. We could additionally announce deprecations elsewhere as well, but I think the problem you may be alluding to is not really a "where we do the announcement" problem but rather a "users don't pay attention until its too late" problem. Honestly I'm not really sure how to solve that one, as no matter how many channels we announce it from, the form that problem takes is invariably that the user didn't look in the right place. My personal opinion is that we shouldn't announce it in a different place, but rather only do so in one single place, and start educating users on what they should do for every release. That is to say, for every release (even if they don't plan to upgrade), users should:
Maybe a wiki page about this would be beneficial |
|
Whether its by mailing list or blog, that is a bit more direct than just polling a file. I think it may be too late by the time someone notices it in a committed file. |
|
That's a fair position, but I'm not sure I agree with it, or perhaps it might be more accurate to say I'm not sure it really makes anything better. The situation as I see it is that, for a given release, end users need to recognize that, even if there is no plan on their part to make use.of the release, that there is action for them to take. Specifically they need to review the release, and identify deprecated apis that they may need to be prepared to stop using (among any number of other things). We can push that information to them in a multitude of ways, but if they don't take the.above requirement to heart, it's going to result in varying degrees of "I didn't know this was happening" complaints. I wonder if there may be a way to have users subscribe to API surfaces to get notified.if changes pertainin to them. |
No description provided.