Roadmap

Ilya Puchka edited this page Feb 8, 2016 · 25 revisions

This page helps us discuss about the RoadMap of Dip, whether we plan to include some features or not, if some features deserve their own dedicated repository or will be integrated in Core, and if there is an rough date estimation on them

TL;DR: Jump to the Roadmap paragraph below


How we manage Dip's RoadMap on GitHub

GitHub Issues & Labels

For features that are planned even if we haven't started developing them yet, there should be a GitHub issue to define that we plan to do that later

  • Each GitHub issue should be flagged with the Enhancement label to show that it's a feature and not a bug
  • Each GitHub issue will also be eventually flagged with either the Core or Dedicated Repo label to indicate if that feature will be implemented in the AliSoftware/Dip repo and pod directly or as a separate repo.

The idea is that we don't want Dip to grow too big and become a huge machinery with tons and tons of stuff that not everybody might need, so we prefer to split huge extensions in dedicated pods/frameworks/repositories.
For example, Dip extensions for UIKit or AutoInjection mechanisms are examples of stuff that might be implemented in a dedicated pod/framework/repo instead of bloating the main repo.

GitHub Milestones

We'll try to use GitHub Milestones to give an idea of the prioritization of the features and issues, especially a milestone by version. For example this will be used to tell in which version we expect to address each issue.

(Milestones dates might be given too, but in Open Source projects like Dip where people only contribute on their free time and when they have time, those dates are only informal, so don't rely too much on it)


The Roadmap

Version 3.1.0 :white_check_mark:

New features

  • register(.Singleton,tag:) { … } will replace register(tag:instance:)
  • named first runtime argument in resolve methods (#18)

Deprecations

  • register(tag:instance:)
  • resolve(tag:_:) and other resolve methods without named first runtime argument

Version 4.0.0 :white_check_mark:

New features

  • circular dependencies (#11)
  • registering/removing definitions (#11)

Breaking Changes

  • throwing errors instead of fatalError (#15)

Deprecations

none

Obsoleted/Removed

  • register(tag:instance:)
  • resolve(tag:_:) and other resolve methods without named first runtime argument

Version 4.1.0 :soon:

New features

  • auto-injection (#13)
  • multi-injection (#14)
  • default implementations with tags (#20)
  • Thread safety is back (#31)

Dedicated Repo

  • storyboards integration

Deprecations

none

Version 4.1.0 :soon:

New features

  • Swift Package Manager support (#30)
  • DipTagConvertible protocol (?) [^1]
  • Linux compatibility (#44)

[^1]: AliSoftware: interesting idea, I like that. But probably low priority. Ilya: After implementing such protocol I fill like using Tag in DependencyContainer methods is just more clear for consumers. The only value such protocol will add is ability to pass some values as tags without calling tag property on them. Not a big win. So I think it does not worth it.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.