Synchronizing 3.x releases and the schedule

[Jaroslaw Staniek]

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. ​D​id 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20160216/96b71cb6/attachment.htm>