[Kde-pim] kdepim in KDE Applications 14.12

Mon Nov 3 09:01:30 GMT 2014

On Friday 31 October 2014 14.36:40 Aleix Pol wrote:
> On Fri, Oct 31, 2014 at 2:00 PM, Christian Mollekopf <chrigi_1 at fastmail.fm>
> 
> wrote:
> > On Friday 31 October 2014 13.40:24 laurent Montel wrote:
> > > Le Friday 31 October 2014 11:47:57 David Jarvie a écrit :
> > > > On Thu, October 30, 2014 8:24 pm, Albert Astals Cid wrote:
> > > > > El Dijous, 30 d'octubre de 2014, a les 20:41:43, laurent Montel va
> > > > > 
> > > > > escriure:
> > > > >> Le Thursday 30 October 2014 20:16:23 Albert Astals Cid a écrit :
> > > > >> > El Dijous, 30 d'octubre de 2014, a les 13:36:28, Kevin Ottens va
> > > > >> 
> > > > >> escriure:
> > > > >> > > On Thursday 30 October 2014 08:14:03 laurent Montel wrote:
> > > > >> > > > Le Thursday 30 October 2014 01:19:27 Albert Astals Cid a
> > 
> > écrit :
> > > > >> > > > > Hi guys, so Laurent said that for KDE Applications 14.12 we
> > > > >> 
> > > > >> should
> > > > >> 
> > > > >> > > > > ship
> > > > >> > > > > 4.x based versions of kdepim*
> > > > >> > > > > 
> > > > >> > > > > Which brings me to the question, when releasing KDE
> > > > >> > > > > Applications
> > > > >> > > > > 14.12
> > > > >> > > > > should i branch KDE/4.14 to Applications/14.12 and release
> > 
> > that
> > 
> > > > >> or
> > > > >> 
> > > > >> > > > > should
> > > > >> > > > > we keep using the KDE/4.14 branch?
> > > > >> > > > 
> > > > >> > > > For me it will better to use KDE/4.14 branch.
> > > > >> > > > Really I have 4.14 branch + master branch for
> > > > >> > > > kdepimlibs/kdepim/kdepim-runtime and I don't want to download
> > 
> > a
> > 
> > > > >> new
> > > > >> 
> > > > >> > > > branch.
> > > > >> > > > 
> > > > >> > > > It's more easy for me to merge in 4.14 that merge in 4.14 +
> > 
> > 14.12
> > 
> > > > >> > > > branch
> > > > >> > > > and after master
> > > > >> > > 
> > > > >> > > I guess if you go for 14.12 then the 4.14 branch would get
> > > > >> 
> > > > >> discontinued?
> > > > >> 
> > > > >> > Correct.
> > > > >> > 
> > > > >> > > You'd probably still have one branch to deal with, just not the
> > > > >> > > same
> > > > >> 
> > > > >> one
> > > > >> 
> > > > >> > > anymore.
> > > > >> > 
> > > > >> > One thing is that by continuing to ship 4.14 branch (instead of a
> > 
> > new
> > 
> > > > >> > 14.12) we'd highlight more than this is pure maintaince instead
> > > > >> > of
> > > > >> 
> > > > >> "any
> > > > >> 
> > > > >> > new feature".
> > > > >> > 
> > > > >> > For example for kdelibs we're just going to ship KDE/4.14.
> > > > >> > 
> > > > >> > Now the question, is kdepim* not based in kf5 going to be pure
> > > > >> 
> > > > >> maintiance
> > > > >> 
> > > > >> > for now?
> > > > >> 
> > > > >> No dev until now just maintiance.
> > > > > 
> > > > > If it's going to be just maintaince i think i actually prefer not
> > 
> > having
> > 
> > > > > a14.12 branch and just using a longer lived KDE/4.14
> > > > > 
> > > > > Is that fine for you guys?
> > > > 
> > > > Until all the kdepim applications are released for kf5, I don't think
> > 
> > that
> > 
> > > > the KDE 4 branch should be restricted to maintenance only.
> > > 
> > > I am against that there is new feature in kde4 kdepim.
> > > Otherwise I will need to port all to kf5.
> > > So no, kde4 branch is closed for new features.
> > > 
> > > Otherwise nobody will work on kf5 and for the moment there is just me
> > 
> > which
> > 
> > > works on kf5 kdepim.
> > > 
> > > For new string changes you can ask to kde-doc to allow a new string.
> > 
> > IMO it wouldn't be a problem to allow new features in 4.14, but of course
> > it's
> > the responsibility of the person that adds the feature to ensure it makes
> > it
> > into master. It clearly shouldn't be your responsibility (or any single
> > person's for that matter), to port other peoples features.
> > 
> > I'd rather allow some new features in 4.14 to keep people happy, than rush
> > a
> > release of a KF5 based solution. Even though you're currently paving the
> > way
> > mostly alone for the rest of us (thanks!), we'll definitely move to the
> > next
> > version when we get to it =)
> > 
> > Cheers,
> > Christian
> 
> To be honest, I don't really understand this over-conservatism towards Qt5.
> It needs to be adopted, the port is quite forward, as you get to use
> KDELibs4Support.
> 

I'm not aware of any conservatism towards Qt5 at all (certainly not from my 
side).

> I don't think Laurent talked about rush at all. He said he wants features
> in master which is Qt5 and that makes total sense to me.
> 

Which is fine. I just pointed out that it's not mutually exclusive, and as 
long as the respective developer ensures himself that the feature ends up 
everywhere I don't see any harm done. Personally I don't care whether 4.14 (or 
whatever the LTS branch will be called) stays open for features as I'm not 
interested in working on anything else than the future of kdepim once I get to 
it.

My point with regards to "rushing" is that there is quite a chunk of work 
ahead of us making binary incompatible changes IMO. Assuming we end up with 
the same BIC guarantees for the kdepimlibs/akonadi parts, I suggest we wait 
until that is done in order not to have to maintain legacy API for another 
bunch of years.
If the BIC guarantees don't immediately apply with the first release that's
less of a problem of course.

Cheers,
Christian

> FWIW, you cannot allow new features in 4.14, you can have a 4.15 if you
> wish, but 4.14 was frozen longtime ago [1].
> 
> Aleix
> 
> [1]
> https://techbase.kde.org/Schedules/KDE4/4.14_Release_Schedule#Wednesday.2C_J
> une_25.2C_2014:_KDE_SC_4.14_Feature_Freeze
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/