Re: Proposal to formalize end-of-life

[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 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
there.

YMMV

Darald

On Sun, Dec 30, 2012 at 8:56 AM, Erik Huelsmann <..hidden..> wrote:
> Hi Berend,
>
>
> To my knowledge this is not customary. E.g. Subversion has a completely
> independent release schedule from any of the distributions. However, since
> rules and regulations seem to change regularly in the accounting business
> (but not in version control) it seems appropriate to at least provide
> minimal fixes.
>
> Also, accounting data is typically very sensitive data. While version
> control data may be too, one would expect technical people to be able to
> secure it (or to find people to do so for them). But everybody who runs a
> business needs an accounting/ERP package, even if they're technically left
> handed. My idea behind the proposal was that we should facilitate packagers
> to create releases as easily as possible.
>
> Though a different approach could be to estimate that we have 18 months
> between releases. LTS distributions such as Ubuntu LTS and Debian typically
> run for 18 months as well. This would require us to keep support for 36
> months after initial release or rather 18 months after the follow-up
> release. Since this reasoning is independent of individual distros, it's
> probably a better criterion?
>
> Bye,
>
> Erik.
>
>
>
> On Sun, Dec 30, 2012 at 3:42 PM, Berend Tober <..hidden..>
> wrote:
>>
>> Erik Huelsmann wrote:
>> > The last bit means that since 1.3 is packaged in Debian and
>> > Ubuntu LTS, it'll be EOL'd somewhere in 2014 or 2015.
>> > How about that?
>>
>> Is that typical practice? (Seriously ... I do not know.) I mean, to tie a
>> specific package dependency to (possibly many) others decisions about
>> support for their distribution? What if a distribution goes dormant and is
>> never formally EOL'd ... does LSMB get stuck with having to unreasonably
>> follow through on a support commitment for that one customer that never
>> gives up on the no-longer-maintained distribution?
>>
>> My gut feeling is the package should be independent -- unless there is
>> some kind of working agreement between the LSMB team and the distribution
>> maintainer team, but honestly this a decision I do not bring much experience
>> to and so do not really have a good grasp on the up- and down, sides, or
>> what it conventional practice is.
>>
>>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_123012
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>