RE: 3.0.0.1 tarball + signature

2017-01-05 Thread Dag 

Camilla Boemann skrev den 2017-01-03 12:59:
I have prepared a release announcement, but it doesn't say much so 
maybe

someone has suggestions as to what we should highlight?
Since it is mainly a port it isn't that much to highlight, but what *is* 
in and what is *not in* is the main thing imo.



If you want to include some bug fixes also, I have these:

Plan:
Fix crash on startup
Bug: 371930

Avoid crash in special cases (eg. when New is pressed)
BUG: 346976

Fix crash on close
BUG: 373527


Fix printing treeviews
BUG:302916

Add export report definition, fix bug in report import
BUG: 325263

Usability: Never block save, add Milestone option to task dialog
BUG:322661
BUG:352226

Implement sort by wbs to sort by wbs structure and not by the wbs 
code string

BUG:308857

Re-instate handling richtext (description) in reports
CCBUG:329430

Fix potential crash in resource request debug statement
BUG:358674

Re: 3.0.0.1 tarball + signature

2017-01-05 Thread Dag 

Many thanks for your sustained, herculian effort Boudewijn!

Jenkins-kde-ci: calligra master kf5-qt5 » Linux,gcc - Build # 185 - Still Unstable!

2017-01-05 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/185/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 05 Jan 2017 08:33:29 +
Build duration: 38 min

CHANGE SET
Revision 8d2383d29beaaad1ebb0b9de2b73589a8b964cdc by Dag Andersen: (Plan does 
not depend on Kdelibs4Support)
  change: edit plan/libs/kernel/CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 4 test(s), Passed: 150 test(s), Skipped: 0 test(s), Total: 
154 test(s)Failed: TestSuite.libs-koodf-TestNumberStyleFailed: 
TestSuite.libs-pigment-TestColorConversionSystemFailed: 
TestSuite.sheets-ValueConverterFailed: TestSuite.sheets-ValueParser

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 144/171 (84%)FILES 1202/2604 (46%)CLASSES 1202/2604 (46%)LINE 
77554/259049 (30%)CONDITIONAL 51597/282118 (18%)

By packages
  
braindump.braindumpcore
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/134 (0%)CONDITIONAL 0/98 
(0%)
braindump.plugins.stateshape
FILES 4/14 (29%)CLASSES 4/14 (29%)LINE 24/280 (9%)CONDITIONAL 
3/140 (2%)
braindump.plugins.webshape
FILES 4/9 (44%)CLASSES 4/9 (44%)LINE 22/295 (7%)CONDITIONAL 
1/114 (1%)
braindump.src
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/3 (0%)CONDITIONAL 0/0 
(100%)
devtools.rng2cpp
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 600/693 (87%)CONDITIONAL 
596/814 (73%)
filters.libmso
FILES 10/12 (83%)CLASSES 10/12 (83%)LINE 880/7716 
(11%)CONDITIONAL 2165/19897 (11%)
filters.libmso.generated
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 4193/12624 
(33%)CONDITIONAL 3969/23069 (17%)
filters.libmsooxml
FILES 2/35 (6%)CLASSES 2/35 (6%)LINE 3/8010 (0%)CONDITIONAL 
2/24349 (0%)
filters.libmsooxml.generated
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/743 (0%)CONDITIONAL 0/3336 
(0%)
filters.libodf2
FILES 6/29 (21%)CLASSES 6/29 (21%)LINE 97/1606 (6%)CONDITIONAL 
82/2174 (4%)
filters.libodf2.chart
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/582 (0%)CONDITIONAL 0/1321 
(0%)
filters.sheets.excel.sidewinder
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 654/685 (95%)CONDITIONAL 
1918/3502 (55%)
filters.sheets.xlsx
FILES 4/5 (80%)CLASSES 4/5 (80%)LINE 111/281 (40%)CONDITIONAL 
67/460 (15%)
filters.stage.powerpoint
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 1651/2710 
(61%)CONDITIONAL 1999/6134 (33%)
filters.stage.powerpoint.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 56/58 (97%)CONDITIONAL 
92/194 (47%)
interfaces
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 54/61 (89%)CONDITIONAL 
36/73 (49%)
libs.basicflakes.plugin
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 23/31 (74%)CONDITIONAL 
1/8 (13%)
libs.basicflakes.tools
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/819 (0%)CONDITIONAL 0/413 
(0%)
libs.flake
FILES 111/180 (62%)CLASSES 111/180 (62%)LINE 5273/13803 
(38%)CONDITIONAL 2895/9878 (29%)
libs.flake.commands
FILES 19/49 (39%)CLASSES 19/49 (39%)LINE 805/2153 
(37%)CONDITIONAL 410/1380 (30%)
libs.flake.svg
FILES 1/20 (5%)CLASSES 1/20 (5%)LINE 8/2480 (0%)CONDITIONAL 
1/1706 (0%)
libs.flake.tests
FILES 49/49 (100%)CLASSES 49/49 (100%)LINE 3740/3773 
(99%)CONDITIONAL 1718/3394 (51%)
libs.flake.tools
FILES 9/43 (21%)CLASSES 9/43 (21%)LINE 155/1625 
(10%)CONDITIONAL 45/952 (5%)
libs.kundo2
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 205/730 (28%)CONDITIONAL 
69/390 (18%)
libs.main
FILES 27/74 (36%)CLASSES 27/74 (36%)LINE 709/7217 
(10%)CONDITIONAL 771/17161 (4%)
libs.main.config
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/218 (0%)CONDITIONAL 0/478 
(0%)
libs.main.gemini
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/2 (0%)CONDITIONAL 0/0 
(100%)
libs.main.tests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 258/271 (95%)CONDITIONAL 
138/236 (58%)
libs.odf
FILES 39/46 (85%)CLASSES 39/46 (85%)LINE 2087/5584 
(37%)CONDITIONAL 1318/4284 (31%)
libs.odf.tests
FILES 17/17 (100%)CLASSES 17/17 (100%)LINE 4854/5100 
(95%)CONDITIONAL 3516/7158 (49%)
libs.odf.writeodf
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 77/106 (73%)CONDITIONAL 
29/59 (49%)
libs.pageapp
FILES 15/35 (43%)CLASSES 15/35 (43%)LINE 543/3106 
(17%)CONDITIONAL 271/1791 (15%)
libs.pageapp.commands
FILES 3/7 (43%)CLASSES 3/7 (43%)LINE 97/180 (54%)CONDITIONAL 
63/124 (51%)
libs.pageapp.dialogs
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/99 (0%)CONDITIONAL 0/16 
(0%)
libs.pageapp.tests

Re: Version stuff in CMakeLists.txt

2017-01-05 Thread Jaroslaw Staniek 
On 5 January 2017 at 08:59, Dag  wrote:

> Had a closer look at this, and there is some cmake logic when generating
> calligraversion.h:
> Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x will be
> 3.0.x, etc)
> Afaics this scheme only works when a minor version is increased, e.g 3.0.x
> -> 3.1.0.
> Is this a disaster? Probably not. If you add a conditional compile e.g in
> 3.0.1 you cannot test in an unstable release, but that would not be often,
> I think.
>
> Alternatives:
> 1) Add a unstable release number as proposed by Rene.
>
> 2) Drop the special unstable numbers (89, 90..) and use the release number
> as a sequential number.
> E.g: We released stable 3.0.0, so now the unstable will get 3.0.1 (string
> could be 3.0.1 Alpha) and when we make a new release it would be 3.0.2.
> This will give unique and increasing version numbers, with the drawback
> that you can not see from version alone if it is unstable or stable, but we
> can use version string for that.
>
> Opinions?
>
>
IIRC we release no alphas. Even when we had that, we release no alphas the
patch version - for x.y.z (z>0).
x.(y-1).89 is thus compatible with the sequence, it comes after all
x.(y-1).* stable and before the next stable x.y.z.

Between 3.0.0 and 3.0.1 there's no extra number needed.

What we had with the x.y.z.v was special I think. (?)


​


>
> Dag skrev den 2017-01-04 10:45:
>
>> I can't figure out how this is meant to be used.
>>
>> We have now released 3.0.0.1. Next should probably be 3.0.1.
>> So I gather current should be an alpha:
>> Major: 3
>> Minor: 0
>> Release: 89
>>
>> But then we would go backwards to Release: 1 when releasing,
>> and after that we go to Release: 89 again and we can't see
>> what 3.0.89 actually means as it will crop up for every new 3.0 release.
>>
>> Is it just me being confused, or...
>> Anybody?
>>
>


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

Re: 3.0.0.1 tarball + signature

2017-01-05 Thread Jaroslaw Staniek 
On 5 January 2017 at 10:03, Dag  wrote:

> Camilla Boemann skrev den 2017-01-03 12:59:
>
>> I have prepared a release announcement, but it doesn't say much so maybe
>> someone has suggestions as to what we should highlight?
>>
> Since it is mainly a port it isn't that much to highlight, but what *is*
> in and what is *not in* is the main thing imo.
>
>
IMHO ​If it's not​ marked as a big thing, the media and users will
definitely mark this as not important and move over. Inkscape just made a
release that highlights a port to GTK+3 as an important news.

For me this release is more of a "OpenOffice->LibreOffice fork" scale. If
our patch is smaller it's "only" because we have no chaos with German
comments as the original code base :)

It was a huge development and org work to perform the port of Calligra. (In
case of Kexi which is not part of these releases, more than a port is in
the box, there's a lot of polishing and "new" db engine)
I would risk by keeping people in false perception that ports happen by
just running a magical script. If we look at the Plan alone, it depends on
Kexi frameworks that were in development consuming 8 years or so. (We're
still making them KF5-like for the KDE review in 3.1 version).
The readers may be also interested in what a "being a Qt5 app" means (new
tech, more opening to further mobile ports, and after all, a must to be
alive since Qt4 isn't developed anymore).

When the announcement is made I'd add a part for Kexi explaining it has an
independent release schedule.



> If you want to include some bug fixes also, I have these:
>
> Plan:
> Fix crash on startup
> Bug: 371930
>
> Avoid crash in special cases (eg. when New is pressed)
> BUG: 346976
>
> Fix crash on close
> BUG: 373527
>
>
> Fix printing treeviews
> BUG:302916
>
> Add export report definition, fix bug in report import
> BUG: 325263
>
> Usability: Never block save, add Milestone option to task dialog
> BUG:322661
> BUG:352226
>
> Implement sort by wbs to sort by wbs structure and not by the wbs code
> string
> BUG:308857
>
> Re-instate handling richtext (description) in reports
> CCBUG:329430
>
> Fix potential crash in resource request debug statement
> BUG:358674
>
>
>
>


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

Re: 3.0.0.1 tarball + signature

2017-01-05 Thread Boudewijn Rempt 
On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:

> IMHO ​If it's not​ marked as a big thing, the media and users will
> definitely mark this as not important and move over. Inkscape just made a
> release that highlights a port to GTK+3 as an important news.

Um... The version inkscape just released isn't the gtk3 port, it's still
gtk2 based.


-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

2017-01-05 Thread Jaroslaw Staniek 
On 5 January 2017 at 11:05, Boudewijn Rempt  wrote:

> On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
>
> > IMHO ​If it's not​ marked as a big thing, the media and users will
> > definitely mark this as not important and move over. Inkscape just made a
> > release that highlights a port to GTK+3 as an important news.
>
> Um... The version inkscape just released isn't the gtk3 port, it's still
> gtk2 based.
>
> ​I referred to
https://inkscape.org/en/news/2017/01/04/inkscape-version-092-released/
and it ​

​marks C++ upgrade and Gtk3 port as important.
​

>
> --
> Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
>



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

NO MAİL ! NO MAİL ! NO MAİL ! NO MAİL ! NO MAİL ! NO MAİL ! NO MAİL ! NO MAİL ! NO MAİL ! NO MAİL ! NO MAİL !

2017-01-05 Thread Ali Demir 
2017-01-05 12:12 GMT+02:00 Jaroslaw Staniek :

>
>
> On 5 January 2017 at 11:05, Boudewijn Rempt  wrote:
>
>> On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
>>
>> > IMHO ​If it's not​ marked as a big thing, the media and users will
>> > definitely mark this as not important and move over. Inkscape just made
>> a
>> > release that highlights a port to GTK+3 as an important news.
>>
>> Um... The version inkscape just released isn't the gtk3 port, it's still
>> gtk2 based.
>>
>> ​I referred to https://inkscape.org/en/news/2017/01/04/inkscape-version-
> 092-released/
> and it ​
>
> ​marks C++ upgrade and Gtk3 port as important.
> ​
>
>>
>> --
>> Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
>>
>
>
>
> --
> 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
>

Re: Version stuff in CMakeLists.txt

2017-01-05 Thread Dag 

Jaroslaw Staniek skrev den 2017-01-05 10:50:

On 5 January 2017 at 08:59, Dag  wrote:


Had a closer look at this, and there is some cmake logic when
generating calligraversion.h:
Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x
will be 3.0.x, etc)
Afaics this scheme only works when a minor version is increased, e.g
3.0.x -> 3.1.0.
Is this a disaster? Probably not. If you add a conditional compile
e.g in 3.0.1 you cannot test in an unstable release, but that would
not be often, I think.

Alternatives:
1) Add a unstable release number as proposed by Rene.

2) Drop the special unstable numbers (89, 90..) and use the release
number as a sequential number.
E.g: We released stable 3.0.0, so now the unstable will get 3.0.1
(string could be 3.0.1 Alpha) and when we make a new release it
would be 3.0.2.
This will give unique and increasing version numbers, with the
drawback that you can not see from version alone if it is unstable
or stable, but we can use version string for that.

Opinions?


IIRC we release no alphas. Even when we had that, we release no alphas
the patch version - for x.y.z (z>0).
x.(y-1).89 is thus compatible with the sequence, it comes after all
x.(y-1).* stable and before the next stable x.y.z.
Hmmm, do you mean we only release unstable when minor version is 
updated, in which case this will (almost) work?
I think we still have the problem that the version in git will get a 
lower version than the last version released, but as said above we could 
live with that.




Between 3.0.0 and 3.0.1 there's no extra number needed.

What we had with the x.y.z.v was special I think. (?)

Yes, forget that.


​


Dag skrev den 2017-01-04 10:45:


I can't figure out how this is meant to be used.

We have now released 3.0.0.1. Next should probably be 3.0.1.
So I gather current should be an alpha:
Major: 3
Minor: 0
Release: 89

But then we would go backwards to Release: 1 when releasing,
and after that we go to Release: 89 again and we can't see
what 3.0.89 actually means as it will crop up for every new 3.0
release.

Is it just me being confused, or...
Anybody?


--
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 [1]

Links:
--
[1] http://www.linkedin.com/in/jstaniek

Re: Version stuff in CMakeLists.txt

2017-01-05 Thread Jaroslaw Staniek 
On 5 January 2017 at 11:12, Dag  wrote:

> Jaroslaw Staniek skrev den 2017-01-05 10:50:
>
>> On 5 January 2017 at 08:59, Dag  wrote:
>>
>> Had a closer look at this, and there is some cmake logic when
>>> generating calligraversion.h:
>>> Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x
>>> will be 3.0.x, etc)
>>> Afaics this scheme only works when a minor version is increased, e.g
>>> 3.0.x -> 3.1.0.
>>> Is this a disaster? Probably not. If you add a conditional compile
>>> e.g in 3.0.1 you cannot test in an unstable release, but that would
>>> not be often, I think.
>>>
>>> Alternatives:
>>> 1) Add a unstable release number as proposed by Rene.
>>>
>>> 2) Drop the special unstable numbers (89, 90..) and use the release
>>> number as a sequential number.
>>> E.g: We released stable 3.0.0, so now the unstable will get 3.0.1
>>> (string could be 3.0.1 Alpha) and when we make a new release it
>>> would be 3.0.2.
>>> This will give unique and increasing version numbers, with the
>>> drawback that you can not see from version alone if it is unstable
>>> or stable, but we can use version string for that.
>>>
>>> Opinions?
>>>
>>
>> IIRC we release no alphas. Even when we had that, we release no alphas
>> the patch version - for x.y.z (z>0).
>> x.(y-1).89 is thus compatible with the sequence, it comes after all
>> x.(y-1).* stable and before the next stable x.y.z.
>>
> Hmmm, do you mean we only release unstable when minor version is updated,
> in which case this will (almost) work?
>

​After 2.9.11 our 3.0.0 beta was 2.9.8x or so (regardless of the fact if it
was physically released). All version are in sequence as in semantic
versioning.
​As you see minor version was not updated, it was still 9. It turned​ 0
since 3.0.0.

https://community.kde.org/Calligra/Schedules/2.9/Release_Plan



> I think we still have the problem that the version in git will get a lower
> version than the last version released, but as said above we could live
> with that.
>
>
>> Between 3.0.0 and 3.0.1 there's no extra number needed.
>>
>> What we had with the x.y.z.v was special I think. (?)
>>
> Yes, forget that.
>
>>
>> ​
>>
>> Dag skrev den 2017-01-04 10:45:
>>>
>>> I can't figure out how this is meant to be used.

 We have now released 3.0.0.1. Next should probably be 3.0.1.
 So I gather current should be an alpha:
 Major: 3
 Minor: 0
 Release: 89

 But then we would go backwards to Release: 1 when releasing,
 and after that we go to Release: 89 again and we can't see
 what 3.0.89 actually means as it will crop up for every new 3.0
 release.

 Is it just me being confused, or...
 Anybody?

>>>
>> --
>> 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 [1]
>>
>> Links:
>> --
>> [1] http://www.linkedin.com/in/jstaniek
>>
>


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

Re: 3.0.0.1 tarball + signature

2017-01-05 Thread Boudewijn Rempt 
On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:

> On 5 January 2017 at 11:05, Boudewijn Rempt  wrote:
> 
> > On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
> >
> > > IMHO ​If it's not​ marked as a big thing, the media and users will
> > > definitely mark this as not important and move over. Inkscape just made a
> > > release that highlights a port to GTK+3 as an important news.
> >
> > Um... The version inkscape just released isn't the gtk3 port, it's still
> > gtk2 based.
> >
> > ​I referred to
> https://inkscape.org/en/news/2017/01/04/inkscape-version-092-released/
> and it ​
> 
> ​marks C++ upgrade and Gtk3 port as important.
> ​
> 

No: it says "(Future infrastructure changes include switching from bzr to git, 
shifting from Gtk2 to Gtk3, and moving to the C++11 standard.)" I.e., that's 
what they're going to do.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

2017-01-05 Thread Jaroslaw Staniek 
On 5 January 2017 at 11:32, Boudewijn Rempt  wrote:

> On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
>
> > On 5 January 2017 at 11:05, Boudewijn Rempt  wrote:
> >
> > > On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
> > >
> > > > IMHO ​If it's not​ marked as a big thing, the media and users will
> > > > definitely mark this as not important and move over. Inkscape just
> made a
> > > > release that highlights a port to GTK+3 as an important news.
> > >
> > > Um... The version inkscape just released isn't the gtk3 port, it's
> still
> > > gtk2 based.
> > >
> > > ​I referred to
> > https://inkscape.org/en/news/2017/01/04/inkscape-version-092-released/
> > and it ​
> >
> > ​marks C++ upgrade and Gtk3 port as important.
> > ​
> >
>
> No: it says "(Future infrastructure changes include switching from bzr to
> git, shifting from Gtk2 to Gtk3, and moving to the C++11 standard.)" I.e.,
> that's what they're going to do.
>

Sorry, just noticed this, hard grammar to me; regardless, they found it
important to notify users what they do apart of adding features and more
importantly why :)
​



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

Re: Version stuff in CMakeLists.txt

2017-01-05 Thread Dag 

Jaroslaw Staniek skrev den 2017-01-05 11:29:

On 5 January 2017 at 11:12, Dag  wrote:


Jaroslaw Staniek skrev den 2017-01-05 10:50:
On 5 January 2017 at 08:59, Dag  wrote:

Had a closer look at this, and there is some cmake logic when
generating calligraversion.h:
Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x
will be 3.0.x, etc)
Afaics this scheme only works when a minor version is increased, e.g
3.0.x -> 3.1.0.
Is this a disaster? Probably not. If you add a conditional compile
e.g in 3.0.1 you cannot test in an unstable release, but that would
not be often, I think.

Alternatives:
1) Add a unstable release number as proposed by Rene.

2) Drop the special unstable numbers (89, 90..) and use the release
number as a sequential number.
E.g: We released stable 3.0.0, so now the unstable will get 3.0.1
(string could be 3.0.1 Alpha) and when we make a new release it
would be 3.0.2.
This will give unique and increasing version numbers, with the
drawback that you can not see from version alone if it is unstable
or stable, but we can use version string for that.

Opinions?

IIRC we release no alphas. Even when we had that, we release no
alphas
the patch version - for x.y.z (z>0).
x.(y-1).89 is thus compatible with the sequence, it comes after all
x.(y-1).* stable and before the next stable x.y.z.

 Hmmm, do you mean we only release unstable when minor version is
updated, in which case this will (almost) work?

​After 2.9.11 our 3.0.0 beta was 2.9.8x or so (regardless of the
fact if it was physically released). All version are in sequence as in
semantic versioning.

​As you see minor version was not updated, it was still 9. It
turned​ 0 since 3.0.0.

https://community.kde.org/Calligra/Schedules/2.9/Release_Plan

Yes, I see that. It is not what I am talking about.
Can I ask you directly then what to put into CMakeLists.txt so we can 
get it right:


set(CALLIGRA_VERSION_STRING "3.0.0.1")
set(CALLIGRA_STABLE_VERSION_MAJOR 3) # 3 for 3.x, 4 for 4.x, etc.
set(CALLIGRA_STABLE_VERSION_MINOR 0) # 0 for 3.0, 1 for 3.1, etc.
set(CALLIGRA_VERSION_RELEASE 0) # 89 for Alpha, increase for next 
test releases, set 0 for first Stable, etc.

#set(CALLIGRA_ALPHA 1) # uncomment only for Alpha
#set(CALLIGRA_BETA 1) # uncomment only for Beta
#set(CALLIGRA_RC 1) # uncomment only for RC
set(CALLIGRA_YEAR 2017) # update every year





I think we still have the problem that the version in git will get a
lower version than the last version released, but as said above we
could live with that.


Between 3.0.0 and 3.0.1 there's no extra number needed.

What we had with the x.y.z.v was special I think. (?)

Yes, forget that.

​

Dag skrev den 2017-01-04 10:45:

I can't figure out how this is meant to be used.

We have now released 3.0.0.1. Next should probably be 3.0.1.
So I gather current should be an alpha:
Major: 3
Minor: 0
Release: 89

But then we would go backwards to Release: 1 when releasing,
and after that we go to Release: 89 again and we can't see
what 3.0.89 actually means as it will crop up for every new 3.0
release.

Is it just me being confused, or...
Anybody?


--
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 [1] [1]

Links:
--
[1] http://www.linkedin.com/in/jstaniek [1]

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

Links:
--
[1] http://www.linkedin.com/in/jstaniek

Re: Version stuff in CMakeLists.txt

2017-01-05 Thread Dag 
Ahh, just dawned on me where I went wrong. A bug fix release will 
*always* be stable so... no problem.

Thanks for your patience, Jaroslaw.

Dag skrev den 2017-01-05 11:43:

Jaroslaw Staniek skrev den 2017-01-05 11:29:

On 5 January 2017 at 11:12, Dag  wrote:


Jaroslaw Staniek skrev den 2017-01-05 10:50:
On 5 January 2017 at 08:59, Dag  wrote:

Had a closer look at this, and there is some cmake logic when
generating calligraversion.h:
Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x
will be 3.0.x, etc)
Afaics this scheme only works when a minor version is increased, e.g
3.0.x -> 3.1.0.
Is this a disaster? Probably not. If you add a conditional compile
e.g in 3.0.1 you cannot test in an unstable release, but that would
not be often, I think.

Alternatives:
1) Add a unstable release number as proposed by Rene.

2) Drop the special unstable numbers (89, 90..) and use the release
number as a sequential number.
E.g: We released stable 3.0.0, so now the unstable will get 3.0.1
(string could be 3.0.1 Alpha) and when we make a new release it
would be 3.0.2.
This will give unique and increasing version numbers, with the
drawback that you can not see from version alone if it is unstable
or stable, but we can use version string for that.

Opinions?

IIRC we release no alphas. Even when we had that, we release no
alphas
the patch version - for x.y.z (z>0).
x.(y-1).89 is thus compatible with the sequence, it comes after all
x.(y-1).* stable and before the next stable x.y.z.

 Hmmm, do you mean we only release unstable when minor version is
updated, in which case this will (almost) work?

​After 2.9.11 our 3.0.0 beta was 2.9.8x or so (regardless of the
fact if it was physically released). All version are in sequence as in
semantic versioning.

​As you see minor version was not updated, it was still 9. It
turned​ 0 since 3.0.0.

https://community.kde.org/Calligra/Schedules/2.9/Release_Plan

Yes, I see that. It is not what I am talking about.
Can I ask you directly then what to put into CMakeLists.txt so we can
get it right:

set(CALLIGRA_VERSION_STRING "3.0.0.1")
set(CALLIGRA_STABLE_VERSION_MAJOR 3) # 3 for 3.x, 4 for 4.x, etc.
set(CALLIGRA_STABLE_VERSION_MINOR 0) # 0 for 3.0, 1 for 3.1, etc.
set(CALLIGRA_VERSION_RELEASE 0) # 89 for Alpha, increase for next
test releases, set 0 for first Stable, etc.
#set(CALLIGRA_ALPHA 1) # uncomment only for Alpha
#set(CALLIGRA_BETA 1) # uncomment only for Beta
#set(CALLIGRA_RC 1) # uncomment only for RC
set(CALLIGRA_YEAR 2017) # update every year





I think we still have the problem that the version in git will get a
lower version than the last version released, but as said above we
could live with that.


Between 3.0.0 and 3.0.1 there's no extra number needed.

What we had with the x.y.z.v was special I think. (?)

Yes, forget that.

​

Dag skrev den 2017-01-04 10:45:

I can't figure out how this is meant to be used.

We have now released 3.0.0.1. Next should probably be 3.0.1.
So I gather current should be an alpha:
Major: 3
Minor: 0
Release: 89

But then we would go backwards to Release: 1 when releasing,
and after that we go to Release: 89 again and we can't see
what 3.0.89 actually means as it will crop up for every new 3.0
release.

Is it just me being confused, or...
Anybody?


--
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 [1] [1]

Links:
--
[1] http://www.linkedin.com/in/jstaniek [1]

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

Links:
--
[1] http://www.linkedin.com/in/jstaniek

RE: 3.0.0.1 tarball + signature

2017-01-05 Thread Camilla Boemann 
Sure but I did say in my draft that we are porting and that it sets a bright 
new future – but really for the average user it doesn’t matter much what kind 
of tools we use – it’s what it means for the user that is important

 

From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of 
Jaroslaw Staniek
Sent: 5. januar 2017 11:45
To: Calligra Suite developers and users mailing list 
Subject: Re: 3.0.0.1 tarball + signature

 

 

 

On 5 January 2017 at 11:32, Boudewijn Rempt mailto:b...@valdyas.org> > wrote:

On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:

> On 5 January 2017 at 11:05, Boudewijn Rempt   > wrote:
>
> > On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
> >
> > > IMHO ​If it's not​ marked as a big thing, the media and users will
> > > definitely mark this as not important and move over. Inkscape just made a
> > > release that highlights a port to GTK+3 as an important news.
> >
> > Um... The version inkscape just released isn't the gtk3 port, it's still
> > gtk2 based.
> >
> > ​I referred to
> https://inkscape.org/en/news/2017/01/04/inkscape-version-092-released/
> and it ​
>
> ​marks C++ upgrade and Gtk3 port as important.
> ​
>

No: it says "(Future infrastructure changes include switching from bzr to git, 
shifting from Gtk2 to Gtk3, and moving to the C++11 standard.)" I.e., that's 
what they're going to do.

 

Sorry, just noticed this, hard grammar to me; regardless, they found it 
important to notify users what they do apart of adding features and more 
importantly why :)
​

 



-- 

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

Jenkins-kde-ci: calligra master kf5-qt5 » Linux,gcc - Build # 186 - Still Unstable!

2017-01-05 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/186/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 05 Jan 2017 11:16:08 +
Build duration: 47 min

CHANGE SET
Revision 3a3ee7863b65313f573593bf868584f829b725f2 by Dag Andersen: (Plan: 
klocale.h is from kde4, so remove)
  change: edit plan/libs/kernel/kptlocale.cpp


JUNIT RESULTS

Name: (root) Failed: 4 test(s), Passed: 150 test(s), Skipped: 0 test(s), Total: 
154 test(s)Failed: TestSuite.libs-koodf-TestNumberStyleFailed: 
TestSuite.libs-pigment-TestColorConversionSystemFailed: 
TestSuite.sheets-ValueConverterFailed: TestSuite.sheets-ValueParser

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 144/171 (84%)FILES 1202/2604 (46%)CLASSES 1202/2604 (46%)LINE 
77554/259049 (30%)CONDITIONAL 51597/282118 (18%)

By packages
  
braindump.braindumpcore
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/134 (0%)CONDITIONAL 0/98 
(0%)
braindump.plugins.stateshape
FILES 4/14 (29%)CLASSES 4/14 (29%)LINE 24/280 (9%)CONDITIONAL 
3/140 (2%)
braindump.plugins.webshape
FILES 4/9 (44%)CLASSES 4/9 (44%)LINE 22/295 (7%)CONDITIONAL 
1/114 (1%)
braindump.src
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/3 (0%)CONDITIONAL 0/0 
(100%)
devtools.rng2cpp
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 600/693 (87%)CONDITIONAL 
596/814 (73%)
filters.libmso
FILES 10/12 (83%)CLASSES 10/12 (83%)LINE 880/7716 
(11%)CONDITIONAL 2165/19897 (11%)
filters.libmso.generated
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 4193/12624 
(33%)CONDITIONAL 3969/23069 (17%)
filters.libmsooxml
FILES 2/35 (6%)CLASSES 2/35 (6%)LINE 3/8010 (0%)CONDITIONAL 
2/24349 (0%)
filters.libmsooxml.generated
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/743 (0%)CONDITIONAL 0/3336 
(0%)
filters.libodf2
FILES 6/29 (21%)CLASSES 6/29 (21%)LINE 97/1606 (6%)CONDITIONAL 
82/2174 (4%)
filters.libodf2.chart
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/582 (0%)CONDITIONAL 0/1321 
(0%)
filters.sheets.excel.sidewinder
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 654/685 (95%)CONDITIONAL 
1918/3502 (55%)
filters.sheets.xlsx
FILES 4/5 (80%)CLASSES 4/5 (80%)LINE 111/281 (40%)CONDITIONAL 
67/460 (15%)
filters.stage.powerpoint
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 1651/2710 
(61%)CONDITIONAL 1999/6134 (33%)
filters.stage.powerpoint.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 56/58 (97%)CONDITIONAL 
92/194 (47%)
interfaces
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 54/61 (89%)CONDITIONAL 
36/73 (49%)
libs.basicflakes.plugin
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 23/31 (74%)CONDITIONAL 
1/8 (13%)
libs.basicflakes.tools
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/819 (0%)CONDITIONAL 0/413 
(0%)
libs.flake
FILES 111/180 (62%)CLASSES 111/180 (62%)LINE 5273/13803 
(38%)CONDITIONAL 2895/9878 (29%)
libs.flake.commands
FILES 19/49 (39%)CLASSES 19/49 (39%)LINE 805/2153 
(37%)CONDITIONAL 410/1380 (30%)
libs.flake.svg
FILES 1/20 (5%)CLASSES 1/20 (5%)LINE 8/2480 (0%)CONDITIONAL 
1/1706 (0%)
libs.flake.tests
FILES 49/49 (100%)CLASSES 49/49 (100%)LINE 3740/3773 
(99%)CONDITIONAL 1718/3394 (51%)
libs.flake.tools
FILES 9/43 (21%)CLASSES 9/43 (21%)LINE 155/1625 
(10%)CONDITIONAL 45/952 (5%)
libs.kundo2
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 205/730 (28%)CONDITIONAL 
69/390 (18%)
libs.main
FILES 27/74 (36%)CLASSES 27/74 (36%)LINE 709/7217 
(10%)CONDITIONAL 771/17161 (4%)
libs.main.config
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/218 (0%)CONDITIONAL 0/478 
(0%)
libs.main.gemini
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/2 (0%)CONDITIONAL 0/0 
(100%)
libs.main.tests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 258/271 (95%)CONDITIONAL 
138/236 (58%)
libs.odf
FILES 39/46 (85%)CLASSES 39/46 (85%)LINE 2087/5584 
(37%)CONDITIONAL 1318/4284 (31%)
libs.odf.tests
FILES 17/17 (100%)CLASSES 17/17 (100%)LINE 4854/5100 
(95%)CONDITIONAL 3516/7158 (49%)
libs.odf.writeodf
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 77/106 (73%)CONDITIONAL 
29/59 (49%)
libs.pageapp
FILES 15/35 (43%)CLASSES 15/35 (43%)LINE 543/3106 
(17%)CONDITIONAL 271/1791 (15%)
libs.pageapp.commands
FILES 3/7 (43%)CLASSES 3/7 (43%)LINE 97/180 (54%)CONDITIONAL 
63/124 (51%)
libs.pageapp.dialogs
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/99 (0%)CONDITIONAL 0/16 
(0%)
libs.pageapp.tests

Jenkins-kde-ci: calligra master kf5-qt5 » Linux,gcc - Build # 187 - Failure!

2017-01-05 Thread no-reply 

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/187/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 05 Jan 2017 12:04:16 +
Build duration: 22 min

CHANGE SET
Revision c769476b16068a82c20e195134e7c32ae7c7a081 by Dag Andersen: (We should 
accept all 3.0 versions of KReport/KProperty)
  change: edit CMakeLists.txt

Re: 3.0.0.1 tarball + signature

2017-01-05 Thread Jaroslaw Staniek 
On 5 January 2017 at 12:25, Camilla Boemann  wrote:

> Sure but I did say in my draft that we are porting and that it sets a
> bright new future – but really for the average user it doesn’t matter much
> what kind of tools we use – it’s what it means for the user that is
> important
>

​Yes, I think the above is sufficient. Our audience are contributors so
it's not nonimportant IMHO but deserves separate section just like we
always do :)
Thanks.


>
> *From:* calligra-devel [mailto:calligra-devel-boun...@kde.org] *On Behalf
> Of *Jaroslaw Staniek
> *Sent:* 5. januar 2017 11:45
> *To:* Calligra Suite developers and users mailing list <
> calligra-devel@kde.org>
> *Subject:* Re: 3.0.0.1 tarball + signature
>
>
>
>
>
>
>
> On 5 January 2017 at 11:32, Boudewijn Rempt  wrote:
>
> On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
>
> > On 5 January 2017 at 11:05, Boudewijn Rempt  wrote:
> >
> > > On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
> > >
> > > > IMHO ​If it's not​ marked as a big thing, the media and users will
> > > > definitely mark this as not important and move over. Inkscape just
> made a
> > > > release that highlights a port to GTK+3 as an important news.
> > >
> > > Um... The version inkscape just released isn't the gtk3 port, it's
> still
> > > gtk2 based.
> > >
> > > ​I referred to
> > https://inkscape.org/en/news/2017/01/04/inkscape-version-092-released/
> > and it ​
> >
> > ​marks C++ upgrade and Gtk3 port as important.
> > ​
> >
>
> No: it says "(Future infrastructure changes include switching from bzr to
> git, shifting from Gtk2 to Gtk3, and moving to the C++11 standard.)" I.e.,
> that's what they're going to do.
>
>
>
> Sorry, just noticed this, hard grammar to me; regardless, they found it
> important to notify users what they do apart of adding features and more
> importantly why :)
> ​
>
>
>
>
>
> --
>
> 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
>



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