-
-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V4.0.0: let's make all the breaking changes #1681
Comments
We could also define what breaking changes are going to v3 and what breaking changes are going to v4. For instance i was thinking about the flex refactoring, it would be great to also make some components for octoprint's visual library to simplify theming and avoid some redundancy i've observed, but that may as well be too big and too long of a change for now to also refactor to more components. This can then be divided in flex for v3 and component modularity for v4. |
How long would this postpone the v3 release? I would rather push all the flex changes to v4 together with the angular components (I guess that's also what you're meaning with octoprint's visual library?). |
Yeah that sounds reasonable, i think i will not have that much time available to refactor octodash in the next 2 weeks so that would probably delay it too much. Could we create the v4 milestone and start linking breaking changes that we will do after v3 release? |
There has been a lot going on in the background. There probably is going to be a v2.2.0 release within the next days, which will include all the new features. V3.0.0 will then be released a couple weeks after and will include major changes to the way OctoDash is run (no need for ratpoison anymore) and installed (different way of packaging). Since we now have the breaking issue label we can safely close this issue I assume and then just sort by breaking. |
Hey,
As V3.0.0 is approaching, i suggest that we delay it maybe a few more day and bake in all breaking changes that may be pending in issues.
Everybody hates breaking changes, and at least themers will have to work behind the release to unbreak the changes. With that in mind, the less often we do it, the better.
I propose that we list here any open issue that may induce breaking changes and check whether it's doable to include them in the release.
The first one that comes to mind is the flex refactor. Because it moves html elements around, it will break themes and it already started. I'm up to remake most interfaces to flex.
The text was updated successfully, but these errors were encountered: