[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LedgerSMB 1.3.6-rc1 released
- Subject: Re: LedgerSMB 1.3.6-rc1 released
- From: Chris Travers <..hidden..>
- Date: Fri, 25 Nov 2011 14:46:36 -0800
On Fri, Nov 25, 2011 at 6:08 AM, David A. Bandel <..hidden..> wrote:
> On Thu, Nov 24, 2011 at 18:11, Chris Travers <..hidden..> wrote:
>> Ok. So with a server, my primary concern is that upgrading things is
>> always a somewhat risky process. Basically, when you upgrade, you
>> risk breaking things, so generally speaking you want to have longer
>> terms of support and a more lazy upgrade cycle. And there are a
>> couple things about the Fedora upgrade process that are particularly
>> risky. For example yum distrosync will upgrade major versions of
>> PostgreSQL for you, meaning if you didn't dump your data first, your
>> PostgreSQL db is now unusable.
> I hope you're joking. While a Debian upgrade is not the easiest thing
> in the world (they do their best to make it so, though), at least this
> is not an issue. You run postgresql versions in parallel until you
> finally get rid of the old one because the new one works properly for
I am not joking. I always back up before an upgrade....
fortunately.... but I have noticed this happen.
> I've gone through 8.4->9.0->9.1 (and many before I can't remember)
> upgrades w/ no problem (personally I use testing, even for my own
> servers). With Debian, they leave both database versions running
> until you've dealt with any upgrade issues. So far, I've only had
> one, that was when a contrib stored procedure I was using didn't make
> it from 8.4->9.0 (but it appeared again in 9.1).
That's the right way to do things.
>>>> The problems that Darald brings up are real ones. There may be
>>>> advantages for us devs ignoring these and working on short-term
>>>> support releases ourselves. However I would not today use these in
>>>> setting up servers for customers.
> As I mentioned before, I find Debian testing to be sufficiently
> bleeding edge to catch problems before my clients see them -- and yes,
> I eat my own dog food (a la Debian testing). I would never suggest
> Debian unstable (they really should call it Debian broken, as it
> usually is).
Unstable is unstable? Whoda thunk?
> I diverge from Debian testing on one point:
> Except for _base_ Perl modules, I load and update directly from CPAN.
> I'm actually not sure why distros don't just do this. It's a lot
> easier than trying to keep thousands of individual modules updated.
>>>> Debian is not a bad distro, and neither is Scientific Linux.
> Scientific Linux will likely be Debian testing -- guess I should check
> it out sometime.
While CentOS is an RHEL clone, Sceintific Linux is an RHEL extension.
It's RHEL plus other things built from sources.....
>>> I might have a look at a virtual SL setup now on your recommendation!
>> Scientific Linux has a couple things to recommend it as a Server OS.
>> 1) It tracks Red Hat Enterprise in both support and versions.
>> 2) It includes a lot of things that RHEL doesn't include
>> 3) They beat CentOS to releases.
>> 4) They are backed by heavy Linux users (Fermi Labs, CERN)
> I believe we do need devs using both RH and Debian based development
> platforms (though not necessarily both), and it sounds like that's
> already happening.
Yep and has been for the entire history of the project.
> I have had in mind putting up a Debian stable Virtual Box image w/
> LedgerSMB that users could just import and go. Guess I'll need to
> work on that ASAP. But will also put up a Debian testing development
> environment (with a few extra goodies) built from svn. Virtual Box's
> clone facility makes this task easy.
> I guess I could also put up an RH-based box as well, although it is
> probably better if someone more familiar w/ RH did that. It's been a
> few years since I admin'd anything RH based (so long, in fact, that
> yum didn't exist).