Tim, Marc, To be sure: we all want to have such an incremental upgrade mechanism. We all know it' s a real PITA, devs, qa testers, localizers, etc. We have inherited from a very problematic codebase and things do not happen overnight. But I am confident they will happen. Best, Charles. Le 6 juin 2012 18:39, "webmaster-Kracked_P_P" <webmaster@krackedpress.com> a écrit :
On 06/06/2012 11:28 AM, Charles-H.Schulz wrote:Hello Marc, Le mercredi 06 juin 2012 à 11:04 -0400, Marc Paré a écrit :Le 2012-06-06 06:12, Charles-H. Schulz a écrit :Interesting ideas here... I wonder how we could plot this with respect to our existing resources. The key issue here is resources . LTS only makes sense if you derive revenue from it.I think we could relabel one branch as LTS, the older one if it brings more clarity. It will work for one year. I don' think working on a branch for 5 years makes sense for a FOSS project, as -again- the examples pointed out stem from commercial offerings (even Mozilla with all its resources only provide a one year support and Canonical or Red Hat offer paid-for support for customers paying each year))Not necessarily. An LTS version is by name only that: "a long term support version" and does not in itself bring on any connotation of any revenue generation for LibreOffice nor any other software company. Imagine all of our large-scale installations that are now occurring in the EU and BR. When they find out that they will have to change on a more frequent basis to keep up with bug fixes (our present model will only bug-fix for only the previous version and not any versions prior to this); at some point, there will be some sort of rationalization of their use of their large-scale LibreOffice installation and their TCO (total cost of ownership). If there are any other office suites (MSO, AOO) that offer any product with LTS (you may call it whatever you wish, ESR-extended support release ...), then, the cost related to continual update/upgrade-testing will put LibreOffice at a clear disadvantage over any LTS-version-office-suite. I cannot imagine a government entity or large institution/business opting for costly installation/retraining costs ad infinitum ... there will eventually be a breaking point and the loss will be ours to bear.I see your point, but perhaps my answer will sound pessimistic: even with a LTS version things will not improve. The reason is simple: there are two different issues that are mixed: one is the incremental update and the other one is the support duration of a version. Let's say we have a LTS version as you propose. Let's say we commit to 5 years of support(!!!). How do security fixes and other patches get pushed to this version? Today, it's done by... redownloading a ful version of LibreOffice. So today it makes sense, after one organization has deployed, say, 3.x.3 to migrate to a 3.x.4 because that's where the patches will be anyway. Today we cannot patch a version and send the update over to one instance. I think that's the real crux of the problem. Otherwise, we would say, in a month or so: "the 3.5 (note the numbering here) is our LTS release". And anything that would need to be patched would be patched incrementally. No need to redownload another version of LibreOffice. Basically what I'm saying is that -while I think the LTS is mostly a business issue because it requires a lot of resources to produce and maintain a LTS- until we have an incremental updates mechansim, our present discussion is not moot, but close to it. Because we're stuck in a situation where the only thing we could say is: "get this version (say, the 3.5.4), it's very stable. If you need updates, we'll have to redeploy". And there's really no other way to go about it, and it's the same for AOO btw. Best, Charles.MSO is still on 2010 version, but they patch it - whenever they choose. So some would say MSO is using a LTS model. For me, I would love it when the patch process model for LO is worked out. Then we will not need to have the issues of reinstalling a full version every few months. As for LTS, well as I stated before, one we get to the last version of a line, it would be nice to have a bug fix or two for that one while we wait for the last version of the current line. That might be a step towards the LTS model. There could be a 3.5.6.a/b or 3.5.6.1/2 for a bug fix release while people can work out all the issues for the 3.6.x line. Then the process starts over again with the 3.6 vs. 3.7 lines. Would there be any support for doing a bug fix for a .6 version while working on the .3 or .4 version of the next line? For businesses it might work. But the real need would be getting a patch cycle work out. But it takes a lot of extra work to do a patch cycle than it does to what is done now. With installing all the .deb files, it might be easier than it would be to patch a Windows version. But it still would be a harder process than the current release model. Currently, how many individual files must be compiled for a total release for all OS versions? How many .deb files are in the 64-bit version that must be installed with "dpkg"? Each one of them has to be compiled/make[d] individually - right? I do not want to think about what is needed to be done to change to a patch cycle model that would go along with a LTS release model. As Marc and others have stated, it takes a lot of IT time to test and deploy a package for a 50+ user business/school/agency. They would not be able to do this for every version or even every second or third version of a LO line. SO there may need to be some type of LTS model in place to encourage them to use LO. Even if it is just sticking with the .6 versions. But, TDF/LO will need to do something to make it more business-friendly as in the case of release cycle patching or LTS release cycle. The better LO can be marketed to their support needs, as well as the features they need, the more business users we get and hopefully the better it will look as a market contender - inside and outside the open source community/market. -- Unsubscribe instructions: E-mail to marketing+help@global.** libreoffice.org <marketing%2Bhelp@global.libreoffice.org> Problems? http://www.libreoffice.org/**get-help/mailing-lists/how-to-** unsubscribe/<http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/> Posting guidelines + more: http://wiki.**documentfoundation.org/** Netiquette <http://wiki.documentfoundation.org/Netiquette> List archive: http://listarchives.**libreoffice.org/global/**marketing/<http://listarchives.libreoffice.org/global/marketing/> All messages sent to this list will be publicly archived and cannot be deleted
-- Unsubscribe instructions: E-mail to marketing+help@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/marketing/ All messages sent to this list will be publicly archived and cannot be deleted