Awesome: Any plans to keep config compatibility?

Created on 24 Jan 2017  路  5Comments  路  Source: awesomeWM/awesome

Hello

First I wan't to thank you for AwesomeWM, it is just awesome indeed!

I was wondering if there is any plan to keep backward compatibility for the configs. I understand some changes are often necessary indeed to keep pushing forward the development process, but do you think the API will be mature enough soon in the sense of avoid these configs compatibility issues?

I recently updated to v4 and some of my configs broke. The same thing happened with the upgrade to the 3.5.

Thank you very much.

discussion

Most helpful comment

The next API breaking release will be v5.0. Keeping compatibility is next to impossible for projects such as Awesome as we give full access to the WM internals. Not breaking the API would be equal to stopping development. As concepts get better defined and partitioned, changes are to be expected. This is the downside of far reaching frameworks like Awesome and could only be limited by filtering what's part of the API and what's "internal behavior". It is against the project mission and therefor wont happen. We never claimed the API was fixed and probably wont ever freeze it.

That being said, we know the changes are causing frustration by some users and we understand that. We are not breaking things for fun or disregard our users time invested into their Awesome configs. This was the first API break in 4 years, that's already quite good. The next API break will probably be sooner than that as the development is currently quite active, but it probably wont be as "large" as 3.4->3.5 or 3.5->4.0 were.

The new (v4) API is more consistent and future proof than the old one was.

All 5 comments

The next API breaking release will be v5.0. Keeping compatibility is next to impossible for projects such as Awesome as we give full access to the WM internals. Not breaking the API would be equal to stopping development. As concepts get better defined and partitioned, changes are to be expected. This is the downside of far reaching frameworks like Awesome and could only be limited by filtering what's part of the API and what's "internal behavior". It is against the project mission and therefor wont happen. We never claimed the API was fixed and probably wont ever freeze it.

That being said, we know the changes are causing frustration by some users and we understand that. We are not breaking things for fun or disregard our users time invested into their Awesome configs. This was the first API break in 4 years, that's already quite good. The next API break will probably be sooner than that as the development is currently quite active, but it probably wont be as "large" as 3.4->3.5 or 3.5->4.0 were.

The new (v4) API is more consistent and future proof than the old one was.

Related (modularized config): https://github.com/awesomeWM/awesome/issues/442

Here is an idea (if applicable and if it could be implemented):

Split the awesome config in two layers, one which only involves code and another one which only involves values and relate them somehow. A similar idea of using environment variables (12 factors)

In this way, people who use awesome's default config but just change the shortcuts can upgrade easily without breaking the configs. People who like to go deeper into customization would still have the same issues, but overall if this is possible I think it will benefit both of them at some point.

I hope I could explain myself if not, I will try to elaborate further.

Best regards.

@vonpupp I'm sorry to say that, but what you are describing is the beautiful module and themes.

(closing because there isn't anything else to say, the plan hasn't changed and there is too many open issues)

Was this page helpful?
0 / 5 - 0 ratings