[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal to formalize end-of-life
- Subject: Re: Proposal to formalize end-of-life
- From: Chris Travers <..hidden..>
- Date: Sun, 30 Dec 2012 08:05:22 -0800
On Sun, Dec 30, 2012 at 7:32 AM, o1bigtenor <..hidden..>
Top posting to follow present custom!
Speaking as a business owner I am much more likely to run for far
longer than 36 months. I know people running businesses using record
keeping (its not really accounting) software that is 7 to 10 years
old. As long as the computer works they are happy. Forcing upgrades
means that you are requiring such individuals to become more computer
savvy than they might want to. As there are millions of
people/businesses out there using very old versions of the windows
based competitors - you may want to look at their problems. One of the
reasons for a regular update is associated employee deductions - if
that is not being used (or is perceived as not important) then there
is no real incentive to upgrade.
I think there are several questions that remain unanswered when we talk about end of life.
I think the thorny issue is going to come up when we talk about upgrade paths. I would like to deprecate 1.2 after 1.4 for upgrade purposes. The major reason there is that 1.2 is really clunky db-wise and there are a lot of db issues that have been tightened up since then. This makes upgrades a bit of a pain.
However in all cases, I think what we are talking about with support is "a community supported and maintained codebase" and the form of that support. Beyond the support period, there are support options available for the indefinite future. The question however is how long the development community can maintain the codebase as a community project.
I switched from Fedora to Debian primarily because I got real tired
of the forced upgrades. I look for things that work, that let me work
the way that I think and don't MAKE me change things on any short term
kind of basis. In this I don't think that I'm to different from many
major companies - - most of the software using for stock and checkout
at my grocery stores is actually in the 25 to 40 year old range - - of
course with a few tweaks and hacks but its OLD. Now this causes other
issues so I'm NOT advocating 25 to 40 year software lifespan just
pointing out the incredible levels of software longevity that are out
We aren't really talking about forced upgrades here. The key issue is where we put our effort and what we can guarantee as a community. Beyond that there are certainly going to be options for whatever support you need,.