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
Attachment:
signature.asc
Description: This is a digitally signed message 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.
