release schedule proposal

Jaroslaw Staniek staniek at
Mon Feb 7 19:28:37 CET 2011

On 7 February 2011 13:50, Boudewijn Rempt <boud at> wrote:
> On Monday 07 February 2011, Jaroslaw Staniek wrote:
>> On 7 February 2011 11:21, Boudewijn Rempt <boud at> wrote:
>> > On Monday 07 February 2011, Jaroslaw Staniek wrote:
>> >
>> >> Extend the co-installability to the snapshots. What means Calligra not
>> >> only can be co-installable with the GroupA-Office but also with the
>> >> latest (or any) stable Calligra release. I see value in this and the
>> >> effort at the side of packagers would be decreased.
>> >> Technical means for this would be using either directory prefixes or
>> >> file name prefixes.
>> >
>> > It will be a lot of work... I don't see the value of it, especially if it means we need to do something to every snapshot. I want to get these snapshots out as soon as possible, with minimal effort that detracts from development.
>> >
>> Installing to prefix shouldn't be a hack.
>> Even the harder way: name prefixes is also possible to deliver once
>> and then have it updated automatically. CMake offers variable
>> expanding everywhere, and the values of the prefix(es) can be used in
>> the .cmake config files and thus in the code.
>> But yes, the first try would be to look at having the cointallability
>> using a custom prefix like in /opt/calligra/year-month/ .
> I'm horribly afraid that that would mean a user would end up with four, five or more installations of calligra in /opt -- and with path and other environment variables pointed to all of them.
> Every snapshot should be an upgrade of the previous one and replace it -- just like the last snapshot should be replaced by
> the first real alpha release. And I'd leave it to the distributions to figure out what location would be best for their users.

The /opt is only recommendation, but without any recommendation,
distros will keep the /usr prefix as the effortless, thus we'd end up
with no co-installable snapshots.

You're right that 100% coinstallable snapshots would be a mess _if_
user adds each bin directory to the $PATH. I am assuming that's not
the case. I see real value of this project: once developed, we can
have this scenario possible:

1. User reports a problem X in Calligra-May-2011 on platform FOO where
we do not really have competence or access.
2. We are're asking for installation of Calligra-April-2011. The user
does so using the standard installation feature of the OS.
3. User executes Calligra-April-2011 from the KDE menu, where the
snapshot is available as a submenu. User admits the problem X
disappeared but she mentions about problem Y in Calligra-April-2011,
already reported.
4. We're asking to try Calligra-May-2011 since we have the problem Y fixed.
5. User still have Calligra-May-2011 from the previous installation
too, so executed it again from the KDE submenu and confirmed that Y is
indeed fixed.

Note 1: During all the steps user can easily identify snapshot version
of the running applications printed on the title bars.
Note 2: Any semi-automatic reports to include the version
of the snapshot used.
Note 3: Regardless of the above steps being performed by the user,
she's using the latest stable installation of Calligra Words to
prepare her documents. She uses Plasma desktop activities for that,
while for testing, Test activity is defined.

regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra (,,
 KDE Software Development Platform on MS Windows (

More information about the calligra-devel mailing list