How to number components of Calligra 3

Jaroslaw Staniek staniek at kde.org
Sun Jul 3 00:10:52 BST 2016


How to number components of Calligra 3? I mean apps and libs.

In the "state of release and release plan" we're discussing whether to
release together, how "much" together, and what are the challenges.
(I shared some facts regarding Kexi, understanding the topic may seem
a minor one compared to porting statuses and so on)

There's the thing of unbalanced development speed within Calligra. To
be honest I find it a nature of software suites (not just office
suites). For example there were many releases of MS Office where some
apps received cosmetic changes and some other apps more than cosmetic.

The inequality would be sooner or later visible again for Kexi with
then a major redesign of its visible cover/UX gets released.
When that happens? Using the traditional numbering maybe 3.1 or 3.2.
2.0 was a big leap because of switching to Qt 5, and here is another
leap. That's the problem for someone who would rather see the change
causing the bump to 4.0. But then why 3.0 so closely to 4.0 in time?
These may be the natural questions among users.

While we want a clear and pretty standard versioning scheme, changes
like these happen and the traditional x.y.z scheme can look less
natural and makes life easier mostly for packagers. How to handle the
versions is still open question. So far I am looking at possibility of
date-based versioning or frequent major version numbering changes. I
think we discussed some of that before.

Some reasoning again. More often than not we have an X.0 version that
is much different than X.1 version. Then there are X.2 versions and so
on that introduce little changes in some apps and dramatic changes in
other apps. In case of the latter apps X+1 release would make sense
already but other apps receive just some bugfixes or sometimes
nothing. Date-based versioning is one approach that would not
emphasize any milestones, it would move us (or those of us that are
interested) effectively closer to rolling releases like the Chromium
project has or frequent number updates like those of Firefox.

With a marketing hat on I'd say how that would work from "customer's"
perspective. Apps would have own version management[1]. And Calligra
as a brand would have own central number that's managed separately as
a part of the product name. For example how about it would be "3" now
and never 3.1 and so on. Thoughts?

[1] PS: 4 or more libraries that split out of calligra.git repo
already have that, officially or will have to have separate versioning
once binary
compatibility comes to the table.

-- 
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



More information about the calligra-devel mailing list