Re: BC problem in kdepimlibs/kcal/calendarresources.cpp

2009-03-21 Thread Tom Albers
Op Saturday 21 March 2009 18:55 schreef u:
> Op Saturday 21 March 2009 18:16 schreef u:
> > Op Friday 20 March 2009 13:19 schreef u:
> > > Hi,
> > > 
> > > In commit 926668 to trunk/KDE/kdepimlibs/kcal/calendarresources.cpp I 
> > > accidentally broke binary compatibility.
> > > 
> > > This commit was back ported to branch 4.2 and is present in KDE4.2.1.
> > > 
> > > Now I fixed it so it's BC with 4.0, 4.1, 4.2.{0, 2, ...}, 4.3 ... just 
> > > not 
> > > 4.2.1 :(
> > > 
> > > Commits which broke BC are:
> > > trunk - 926668
> > > branch4.2 - 926671
> > > 
> > > Commits which fixed BC are:
> > > trunk - 941693
> > > branch4.2 - 941695
> > > 
> > > 
> > > 
> > > I apologize for any inconvenience. 
> > 
> > Hi,
> > 
> > Those things happen. 
> > 
> > But although the damage has been repaired, it leaves us with a 4.2.2 which
> will
> > be BIC against 4.2.1. So I think we *must* bump the so-version now.
> > 
> > Toma
> 
> Actually it is about a boolean added to the .h, which is not BIC. Removing it
> for 4.2.2 would be.
> 
> If this is correct, I suggest to re-add a dummy bool, with a comment to remove
> that for kde5.
> 
> Best,
> 
> Toma

This is not correct, it was bic. People on irc tell me to not bump so for this. 
So, lets leave it as is. Sorry for the noise...

Toma
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: BC problem in kdepimlibs/kcal/calendarresources.cpp

2009-03-21 Thread Andreas Pakulat
On 21.03.09 18:16:31, Tom Albers wrote:
> Op Friday 20 March 2009 13:19 schreef u:
> > Hi,
> > 
> > In commit 926668 to trunk/KDE/kdepimlibs/kcal/calendarresources.cpp I 
> > accidentally broke binary compatibility.
> > 
> > This commit was back ported to branch 4.2 and is present in KDE4.2.1.
> > 
> > Now I fixed it so it's BC with 4.0, 4.1, 4.2.{0, 2, ...}, 4.3 ... just not 
> > 4.2.1 :(
> > 
> > Commits which broke BC are:
> > trunk - 926668
> > branch4.2 - 926671
> > 
> > Commits which fixed BC are:
> > trunk - 941693
> > branch4.2 - 941695
> > 
> > 
> > 
> > I apologize for any inconvenience. 
> 
> Hi,
> 
> Those things happen. 
> 
> But although the damage has been repaired, it leaves us with a 4.2.2 which 
> will be BIC against 4.2.1. So I think we *must* bump the so-version now.

Qt Software didn't bump their soversion in the 4.4.1 release, so I'm not
sure thats needed. Also bumping soversion would not quite correct, since
4.2.2 is still BiC to 4.2.0 and earlier versions.

Andreas

-- 
Stay away from hurricanes for a while.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: BC problem in kdepimlibs/kcal/calendarresources.cpp

2009-03-21 Thread Tom Albers
Op Saturday 21 March 2009 18:16 schreef u:
> Op Friday 20 March 2009 13:19 schreef u:
> > Hi,
> > 
> > In commit 926668 to trunk/KDE/kdepimlibs/kcal/calendarresources.cpp I 
> > accidentally broke binary compatibility.
> > 
> > This commit was back ported to branch 4.2 and is present in KDE4.2.1.
> > 
> > Now I fixed it so it's BC with 4.0, 4.1, 4.2.{0, 2, ...}, 4.3 ... just not 
> > 4.2.1 :(
> > 
> > Commits which broke BC are:
> > trunk - 926668
> > branch4.2 - 926671
> > 
> > Commits which fixed BC are:
> > trunk - 941693
> > branch4.2 - 941695
> > 
> > 
> > 
> > I apologize for any inconvenience. 
> 
> Hi,
> 
> Those things happen. 
> 
> But although the damage has been repaired, it leaves us with a 4.2.2 which 
> will
> be BIC against 4.2.1. So I think we *must* bump the so-version now.
> 
> Toma

Actually it is about a boolean added to the .h, which is not BIC. Removing it 
for 4.2.2 would be.

If this is correct, I suggest to re-add a dummy bool, with a comment to remove 
that for kde5.

Best,

Toma___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: BC problem in kdepimlibs/kcal/calendarresources.cpp

2009-03-21 Thread Tom Albers
Op Friday 20 March 2009 13:19 schreef u:
> Hi,
> 
> In commit 926668 to trunk/KDE/kdepimlibs/kcal/calendarresources.cpp I 
> accidentally broke binary compatibility.
> 
> This commit was back ported to branch 4.2 and is present in KDE4.2.1.
> 
> Now I fixed it so it's BC with 4.0, 4.1, 4.2.{0, 2, ...}, 4.3 ... just not 
> 4.2.1 :(
> 
> Commits which broke BC are:
> trunk - 926668
> branch4.2 - 926671
> 
> Commits which fixed BC are:
> trunk - 941693
> branch4.2 - 941695
> 
> 
> 
> I apologize for any inconvenience. 

Hi,

Those things happen. 

But although the damage has been repaired, it leaves us with a 4.2.2 which will 
be BIC against 4.2.1. So I think we *must* bump the so-version now.

Toma___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Qt MathML Widget

2009-03-21 Thread Aleix Pol
On Fri, Mar 20, 2009 at 3:37 PM, John Tapsell  wrote:

> 2009/3/20 Aleix Pol :
> >
> >
> > On Fri, Mar 20, 2009 at 3:27 PM, John Tapsell 
> wrote:
> >>
> >> 2009/3/20 Aleix Pol :
> >> > On Wed, Mar 18, 2009 at 1:12 PM, Allen Winter  wrote:
> >> >>
> >> >> Howdy,
> >> >>
> >> >> I assume we are all following the "Qt MathML Widget" discussion on
> >> >> k-c-d.
> >> >> Ideas on that issue?
> >> >>
> >> >> My first thought was sourceforge with some folks to maintain it
> there.
> >> >>
> >> >> kdesupport is basically the same as sourceforge, but somewhat easier
> >> >> to deal with.
> >> >>
> >> >> Would kdelibs be ok? doesn't feel "right" to go there, but I won't
> >> >> object
> >> >> if someone claims maintainership there.
> >> >>
> >> >> ??
> >> >>
> >> >> --
> >> >> Allen Winter | Software Engineer | 1-888-872-9339
> >> >> KDAB, Inc. | "Platform-independent software solutions"
> >> >> http://kdab.com | 1-866-777-5322 (US) | +46-563-540090 (Sweden)
> >> >
> >> > Referring to what thiago macieira said on the k-c-d list, I think that
> >> > he
> >> > has his point.
> >> > We should only put it in kdelibs if we're forking it (what are your
> >> > plans
> >> > john?) and renaming it.
> >>
> >> I think we almost certainly want to do this, and encourage people to
> >> expand on it.
> >>
> >>
> >> >
> >> > Otherwise I'd be fine if it is in a separate library in kdesupport,
> but
> >> > since they don't ensure ABI stability i'm not sure whether that would
> be
> >> > a
> >> > good idea.
> >> >
> >> > Thanks,
> >> > Aleix
> >> >
> >> > PS: I'm not on this list, CC me if tehre is any other message on this
> >> > subject please.
> >> >
> >
> > Wouldn't it be a better idea to keep the work on KFormula? we don't want
> 2
> > KDE codes doing the same thing!
>
> It might be worth dropping the KDE4 KFormula.
> I would suggest either:
>
> *) Go with QtMMlWidget.  It works.  It's read only, but it's still
> useful and if we can pry open the API a bit we could get it working in
> KOffice.  Adding editing can be then done on top, building on an
> already supported base.
>
> *) Redo the port of KDE 3's KFormula, removing the fairly minimal
> KOffice specific code.
>
> I estimate the second option to be a solid two week's work for an
> experienced KDE developer.
>
> I think the first option is the more stable option and is ready now,
> even if it's not up to the feature level of KDE 3's KFormula.
>
> John
>

After some chat between John and me, we decided that, since KFormula might
want to use this QtMMLWidget code at some point but we want that KDE
applications start to take advantage of MathML as soon as possible.
Our idea has been to put it to kdesupport until KFormula has forked it (and
it is working) so that we can deprecate the QtSolution's in kdesupport. Then
KFormula's widget would go to kdelibs.

Is that ok?

Thanks,
Aleix
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Qt MathML Widget

2009-03-21 Thread Aleix Pol
On Fri, Mar 20, 2009 at 3:27 PM, John Tapsell  wrote:

> 2009/3/20 Aleix Pol :
> > On Wed, Mar 18, 2009 at 1:12 PM, Allen Winter  wrote:
> >>
> >> Howdy,
> >>
> >> I assume we are all following the "Qt MathML Widget" discussion on
> k-c-d.
> >> Ideas on that issue?
> >>
> >> My first thought was sourceforge with some folks to maintain it there.
> >>
> >> kdesupport is basically the same as sourceforge, but somewhat easier
> >> to deal with.
> >>
> >> Would kdelibs be ok? doesn't feel "right" to go there, but I won't
> object
> >> if someone claims maintainership there.
> >>
> >> ??
> >>
> >> --
> >> Allen Winter | Software Engineer | 1-888-872-9339
> >> KDAB, Inc. | "Platform-independent software solutions"
> >> http://kdab.com | 1-866-777-5322 (US) | +46-563-540090 (Sweden)
> >
> > Referring to what thiago macieira said on the k-c-d list, I think that he
> > has his point.
> > We should only put it in kdelibs if we're forking it (what are your plans
> > john?) and renaming it.
>
> I think we almost certainly want to do this, and encourage people to
> expand on it.
>
>
> >
> > Otherwise I'd be fine if it is in a separate library in kdesupport, but
> > since they don't ensure ABI stability i'm not sure whether that would be
> a
> > good idea.
> >
> > Thanks,
> > Aleix
> >
> > PS: I'm not on this list, CC me if tehre is any other message on this
> > subject please.
> >
>

Wouldn't it be a better idea to keep the work on KFormula? we don't want 2
KDE codes doing the same thing!
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Qt MathML Widget

2009-03-21 Thread Aleix Pol
On Wed, Mar 18, 2009 at 1:12 PM, Allen Winter  wrote:

> Howdy,
>
> I assume we are all following the "Qt MathML Widget" discussion on k-c-d.
> Ideas on that issue?
>
> My first thought was sourceforge with some folks to maintain it there.
>
> kdesupport is basically the same as sourceforge, but somewhat easier
> to deal with.
>
> Would kdelibs be ok? doesn't feel "right" to go there, but I won't object
> if someone claims maintainership there.
>
> ??
>
> --
> Allen Winter | Software Engineer | 1-888-872-9339
> KDAB, Inc. | "Platform-independent software solutions"
> http://kdab.com | 1-866-777-5322 (US) | +46-563-540090 (Sweden)
>

Referring to what thiago macieira said on the k-c-d list, I think that he
has his point.
We should only put it in kdelibs if we're forking it (what are your plans
john?) and renaming it.

Otherwise I'd be fine if it is in a separate library in kdesupport, but
since they don't ensure ABI stability i'm not sure whether that would be a
good idea.

Thanks,
Aleix

PS: I'm not on this list, CC me if tehre is any other message on this
subject please.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team