Laszlo Papp wrote: >> No, I really do and those qualifiers are required, but note that they apply >> to >> each feature individually. That is, if you want to merge the command-line >> parser, it needs to be feature-complete, working, documented, tested and a >> few >> more qualifiers (cf. Qt Project's "Technical Fit") before I or anyone else >> should click that +2. > > If those all fully apply, I would call it "release" since there is > nothing to fix anymore or stabilize since it is "completely". My point > is that there may be bugs on certain platforms where it is not well > tested, or the documentation is written and approved by developers and > cannot get better until it is released to the public for further > feedback and improvement.
No it is not a release. The point is features are developed outside shared branches until the point where they are ready for wider exposure. It doesn't mean they won't change. But it does mean the feature does something useful (i.e., is not half-broken, doesn't break the build), has tests for the functionality it offers that will be run by the CI gate, has minimal documentation to make it useful to developers wanting to try out or review the feature. Merging a feature to a shared branch means you are publishing it for others to try out and see. The fact that the initial branch is still a development branch means the API/ABI is not immediately set, so it can change. Typically, documentation can be incrementally improved from then on, but it's important to have something to begin with. As much as possible, break big features into smaller incremental ones that can be taken in one at a time and built upon. Again, "complete" is not the same as "frozen". And releasing to a shared branch is still meant to gather feedback and improve. Cheers, João _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development