Closed
Description
This issues is to discuss our management of breaking and non-breaking changes in the 0.x series of releases, to limit the scope of the discussion I suggest this is revised before we stabilise.
As mentioned in #97, the unproven
flag on traits aren't working quite as we might intend.
We've also put forward an feature-flag approach to mitigate the impact of breaking changes to hal traits on library users that I propose we adopt for all future changes.
Please refer to #97 for an introduction to this approach and previous discussion about the unproven
flag.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
therealprof commentedon Oct 3, 2018
@ryankurte Maybe you should should lay out what the vision is regarding the feature-flag approach and create an RFC for the changes this requires.
Regarding the breaking and non-breaking changes and
unproven
flag: IMHO we should encourage people to create pull requests removing theunproven
feature gate by providing references to known implementations which provide and/or use theunproven
trait in question. We'll verify those claims, accept the PR, bump the version and release a new version. For breaking changes we should announce the upcoming change to solicit for more breaking changes and then do the same.However I'm not quite convinced we really need to cause breakage for #97. I'd rather have separate traits for the fallible versions. That way people can easily adjust and bridge between the two versions instead of breaking everything in one swoop.
hannobraun commentedon Oct 3, 2018
@therealprof
I agree. If we decide to keep the
unproven
flag, we should certainly do that.It's not clear to me whether you mean we should have a second set of traits as a transition strategy or permanently.
If you mean adding a second set of traits as a transition strategy, we already discussed this on #95 and #97. I don't remember the details right now, but we agreed the approach currently taken by the pull request is the better one.
If you mean we should add a second set of traits permanently, I strongly disagree. Citing my own comment from #95:
therealprof commentedon Oct 3, 2018
Yes, as a transition strategy.
hannobraun commentedon Oct 3, 2018
Okay, understood. I'm open to discussing the transition strategy, especially since I recently realized we need to add those additional feature flags to the Travis build, then remember to remove them again later. Overall, I don't feel strongly about the transition strategy, as long as the end result is good.
[-]The future of `Unproven` traits and practices for new and breaking changes[/-][+][discussion] the future of `Unproven` traits and practices for new and breaking changes[/+][-][discussion] the future of `Unproven` traits and practices for new and breaking changes[/-][+][Discussion] the future of `Unproven` traits and practices for new and breaking changes[/+]ryankurte commentedon Oct 4, 2018
I've opened an RFC for mitigation of breaking changes in #100.
If we don't have a particular problem with
unproven
except for it's prevalence / longevity, I propose closing this issue in favour of aProve unproven traits
meta issue to work on removing them, any agreement / disagreement?therealprof commentedon Oct 5, 2018
Indeed, my only beef with
unproven
is the longevity. So +1 from me.