KDE release cycles?

[Kevin Krammer]

On Thursday, 2012-04-05, Duncan wrote:
> dE . posted on Thu, 05 Apr 2012 07:23:16 +0530 as excerpted:
> > So 'feature release' may mean (apart form including absolutely new
> > features) -
> > 
> > 1) Restructuring the code (better management).
> > 2) New backend or changed backend which may increase or decrease bugs.
> > 
> > And bug fixes mean fixing small time bugs in library or directly in the
> > app.
> 
> I'll let Kevin respond to that (tho it seems a reasonable summary to this
> non-dev, here),

I agree. My guess is that the term "feature release" is used to indicate that 
this is not just the same thing again.

From a developer's perspective it just means that restrictions on what you can 
do are less tight. There are still things that are not allowed, e.g. changing 
libraries in a way that makes them incompatible with applications, but on the 
application level you can do almost anything you want.

> but there is certainly one practical limitation of the
> bugfix releases as opposed to feature releases:
> 
> * Strings are generally frozen during a six-month bugfix series.  This is
> to help the various l10n (localization, basically, translation) efforts,
> but it DOES mean a tradeoff in terms of fixing things "properly"
> sometimes, if that would mean a UI and string change, even if the actual
> code fix is reasonably small and "safe" and would otherwise be allowed.

Yes, very good observation. Sometimes an essential bug fix needs a string 
change, in which case the translators usually grant an exception [1].

> This is actually one reason the distros tend to ship later bugfix
> releases instead of newer feature releases

One additional thing might be that distributions themselves use a very similar 
development and release model so they have a better understanding what each 
step along the way carries with it.

Early bug fix releases of a feature release are basically more like the public 
beta of proprietary software, i.e. the beta releases of Free Software products 
(and of distributions which do such things) are more like the interal or 
private beta.

Understanding those circumstances can make it a lot easier to get a smooth 
upgrade experience. E.g. on my Kubuntu workstation I always perform version 
upgrades shortly before the next release comes out.
The distribution's release marks the beginning of a public beta phase again, 
so the version right before that is the most reliable state.

Distributions like RHEL or Debian/stable which have upgrade reliability as a 
main focus, do this waiting period internally, i.e. stop adding new versions 
of their "upstream" (Fedora, Debian/testing respectively) for a period before 
doing their release. 

Cheers,
Kevin

[1] once string freeze is active, the translators as the main stake holder of 
user visible text, can grant exceptions to the freeze if they think the benefit 
outweights the additional work.

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20120405/2c008056/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.