-
Notifications
You must be signed in to change notification settings - Fork 30
Roadmap
Freya is a live project, and there are lots of future plans. To help everyone get some clarity on that, we'll try and maintain a public roadmap document which will give people some insight. We also hope that people will get involved - the roadmap isn't set in stone, and if there's something great that people want from Freya, we'll listen where possible!
The 3.0 release of Freya is not a huge one - there's not a great deal in terms of new functionality, but it is a release aimed at tidying up APIs, bringing naming in line with conventions (particularly around Optics) and also reducing the amount of boilerplate in some places, making some APIs more concise (and eliminating some APIs entirely).
Broadly speaking, the changes can be described as follows:
- Optic naming conventions
- Optic module within Freya unifies and replaces the old Lens module
- Some of the conversion methods (
*.toPipeline, etc.) have become obsolete, and are now automatically applied when needed. - Some of the configuration methods in
freyaMachinehave become more intelligent, for example decisions can now accept either aFreya<bool>or a simplebool. - Arachne 3.0
The 4.0 release of Freya will be relatively significant, largely aimed at further simplification, rationalization of APIs, componentization of core functionality, and the development of a more general foundation for routers and - particularly - machines. 4.0 will likely include some breaking changes, while 3.0 supports existing code (although with a number of obsolete code warnings to help people to remove/update code where needed).
The 4.0 release of Freya will be the first once Freya has been moved to the Xyncro organization (for more details on that and the background - and a place to comment - see Freya Move to Xyncro).
The 4.0 release of Freya will also involve a move to break Freya down into smaller groups of components, each with a repository (and an independent release cycle when useful). This means that the core of Freya can remain more stable than newer, or experimental elements, and provides a better enforcement of responsibilities in the overall design. This can be tracked at Repository Structuring.
The 4.0 release of Freya will see a newly redesigned underlying implementation of machines, using a separately split out library, Hephaestus under the hood (although not directly exposed to Freya users). This allows for more powerful graph work, including automatic optimization of graphs, dead code elimination, etc. The standard HTTP machine will be rebuilt to be modular and will automatically include only code potentially required to service a configured resource (which will then be optimized based on configuration). This is likely to be the subject of some blog posts!
Some small changes to the API of the common machine may be needed (and may include a further rationalization of configuration/decision naming if possible - see freyaMachine Decisions naming for discussion.
The 4.0 release of Freya will rationalize some of the type names, removing the Freya prefix from many of the common types, retaining Freya only in suitable places (computation expression names, and some very core type aliases). Backwards compatibility will be a priority where at all possible, although obsolete warnings are likely to be in place until a future 5.0.
After 4.0 is out, the goal over time will be to increase stability around the core of areas of functionality. This is likely to require breaking the repository structure down still further to a one component/one repository/one package granularity, but it's not anticipated that this will be practical until the post-4.0 timeframe. This change should only impact development, and have no impact on end users of Freya. (Thanks to @mexx for raising this prospect!)