How do our contributions fit into the Qt Company's releases?
-
I just want my contributions to have true impact that I eventually might be part of a major new feature versus bug fixing some company's code and the company employees make all the major features
-
I just want my contributions to have true impact that I eventually might be part of a major new feature versus bug fixing some company's code and the company employees make all the major features
then just contribute! e.g. the maintainer for qtbase does not work for the Qt Company and he makes a lot of new features for every release.
what features are you thinking of?
-
Hi,
To add to @aha_1980
- New features goes to the dev branch and if integrated before feature-freeze, they go to the next minor release.
- Bug fixes usually go to the current released version e.g. 5.11 branch
- Bug fixes with deeper impacts go to the dev branch
- Code refactoring usually go to the dev branch.
Refactoring can be:
- Moving code to C++11,
- Move from deprecated to new classes
- etc.
One thing to keep in mind, bug fixing is not second zone development citizen. You can make an even higher impact fixing bugs than implementing a new feature.
[edit: fixed release type for new features SGaist]
-
I just want my contributions to have true impact that I eventually might be part of a major new feature versus bug fixing some company's code and the company employees make all the major features
@i-dream-in-code said in How do our contributions fit into the Qt Company's releases?:
How do our contributions fit into the Qt Company's releases?
See https://www.macieira.org/blog/qt-stats/ for a breakdown.
The most interesting one for you is probably https://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png
I just want my contributions to have true impact that I eventually might be part of a major new feature versus bug fixing some company's code and the company employees make all the major features
Note: Qt is not "The Qt Company's code".
Other companies and individual people can contribute new features too. If you want to contribute a new feature, subscribe to the Development mailing list and post your proposal there.
-
Hi,
To add to @aha_1980
- New features goes to the dev branch and if integrated before feature-freeze, they go to the next minor release.
- Bug fixes usually go to the current released version e.g. 5.11 branch
- Bug fixes with deeper impacts go to the dev branch
- Code refactoring usually go to the dev branch.
Refactoring can be:
- Moving code to C++11,
- Move from deprecated to new classes
- etc.
One thing to keep in mind, bug fixing is not second zone development citizen. You can make an even higher impact fixing bugs than implementing a new feature.
[edit: fixed release type for new features SGaist]
-
Some examples but there might be others:
- Big internals refactoring
- Fix that reaches several modules
- Fix that may change a behaviour
- etc.
-
@SGaist said in How do our contributions fit into the Qt Company's releases?:
Bug fixes usually go to the current released version e.g. 5.11 branch
Bug fixes with deeper impacts go to the dev branchWhats deeper impact of a bug in this case?
@macfanpl said in How do our contributions fit into the Qt Company's releases?:
Whats deeper impact of a bug in this case?
From time to time, users are frustated that with new Qt releases, some bugs affecting them are still not solved. This is just one example of comment in a Qt release announcement:
My app cannot use the Qt 5.12.5 and Qt 5.13.x due to following issue.
https://bugreports.qt.io/browse/QTBUG-77423
This issue is very critical issue because it breaks previous behavior but it still only be opened not progress.So imagine you can fix such bug, you'll make a Qt user very happy I guess :-)
