Dear All, This is an semi-early call. Would you think synchronizing 3.x releases of Calligra apps and components makes sense? After we agree on basic things we may want to develop a 2016 release schedule.
To reduce the work needed, one or two announcements are better than multiple. What are the pros/cons for you? == Some background == I see that KDE Applications or Frameworks (KF5) have synchronized releases. Perhaps for the apps there's a convenience reason. For the frameworks, I've heard cross-dependencies may be the reason. The same as with Qt: private APIs are cross-dependent, either you update entire Qt or not. By frameworks in Calligra case I mean these components: - KDiagram - KDb - KProperty - KReport So we have already quite a few. == Information for someone who missed the changes from 2015 == - we have the above 4 frameworks in separate git repository - we have krita.git, kexi.git - Krita currently has 10 repos for its extensions grouped under the krita-extensions sub-project - calligra.git hosts the other Calligra apps and the libraries shared by these apps, other than Kexi/Krita (Kexi/Krita do not use them, right?) This separation influence changes needed in the release process. Did I miss something? == Helpers == Let me use example for Kexi. The Kexi sub-team maintains 3 repos for components, all but KDiagram, these are deps of Kexi and intended to be generally usable like KF5 modules. And of course maintains kexi.git. This is already different a story than the single repo. We had 2015's discussions on "whether to split calligra.git or not". Complication can be addressed by using certain helpers and workflows. Below I am mentioning just a few points so they can be potentially reused by other sub-projects. And notes will be appreciated. 1. Kexi and its dependencies already use approach of strong versioning: whenever _explicit_ binary incompatibility or large addition appears in the kdb/kreport/kproperty components, version number is bumped and if kexi.git needs these changes, minimal version is updated in kexi.git/CMakeLists.txt. This works quite OK with a rule that such changes happen on Mondays (the term BIC Mondays has been coined). Currently the release (z for x.y.z) version number is bumped but when releases are public, major version should follow BIC changes. (for BIC see e.g. https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B) 2. Announcements and change logs. IMHO, in the modern days readers may skip studying announcements except some feature highlights of major releases, with great screen shots and videos. We're understaffed so this content mainly exists for Krita. At least for the stuff maintained within Kexi I thought about automatic change log generation. Qt uses that approach too, IIRC. For that, quality commit messages with tags such as GUI, FIXED-IN, FEATURE are needed, maybe even enforced by git hooks. I see no reason why it can't use some gui form helper... I'd report any successes on this front. == Further repo splits? == IMHO, also in the future libraries from calligra.git can be extracted if there is real need and a long-term maintainer for that and Calligra 'users' of the libraries accept that. Example: a library from spreadsheet's statistical/etc. formula support looks like something useful for Kexi. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
