Fwd: [Kde-pim] KDEPIM 4.5 releases

[Ryan Rix]

----------  Forwarded Message  ----------

Subject: [Kde-pim] KDEPIM 4.5 releases
Date: Wed 7 July 2010, 1:32:29 am
From: Thomas McGuire <mcguire(a)kde.org&gt;
To: kde-pim(a)kde.org

Hi,

we had a KDEPIM BoF at Akademy today, the meeting notes can be found at 
http://community.kde.org/KDE_PIM/Meetings/Akademy-2010.

Basically the state of KMail 2 is not something that can be called "beta", 
too 
many problems with it, mainly with migration and filtering, but also some 
other blocking issues.

So the plan we discussed basically is:
- The tarball that was created recently and named "beta1" is nowhere near 
  beta1 quality. It is already packaged though, so we can't withdraw it, 
we 
  only can communicate it correctly to manage expectations
- We release a beta version of KDEPIM from the 4.5 branch each time a 
minor
  release of KDE SC 4.5.x is done. This means next beta gets released with 
KDE 
  SC 4.5.0, the one after that with KDE SC 4.5.1 and so on. We release the  
  final version of KDEPIM from the 4.5 branch once we deem it is in a 
  releasable state, at the very least with KDE SC 4.6.0.
- The bugfixing work will take place in the 4.5 branch, not trunk. More on 
  that in a separate email.
- Trunk is open for all commits again, including new strings and features.
  People should work on the 4.5 branch as their main branch though, and 
only 
  commit to trunk in exceptions. Use 4.5 as the main branch to make KDEPIM 
  ready for the release!
  Exceptions to that being, for example:
    - Feature merges from e35, e4 and komo
    - Patches that introduce new features from non-core developers
    - etc
- The Komo branch, where the development for the mobile PIM applications 
was 
  done, will be merged this or next week to trunk, and then removed.
- kdepim and kdepimlibs will depend on kdelibs 4.5.x, _not_ kdelibs trunk. 
  That means no new API from kdelibs trunk may be used.
  As an exception, the macro KDE_IS_VERSION can be used to conditionally 
  compile in stuff that depends on kdelibs trunk. The RTL patch from 
Ebrahim 
  comes to my mind here.
  Note that for now we still depend on kdelibs 4.4, please wait for an 
  announcement from Volker that we can actually depend on kdelibs 4.5. 
Should 
  happen soon.

Please correct me if I missed anything or if something is not correct. 
Also, 
please add any additions if you have.

Regards,
Thomas

-----------------------------------------
-- 
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word         ==