Re: LedgerSMB 1.3.6-rc1 released

[Chris Travers <..hidden..>]

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:
>
> [snip]
>
>>
>> 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
> you.

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.

<snip>

>
>>>>
>>>> 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.
>
>>>
>>> Agreed.
>>>
>>>
>>>> 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).
>
Understood.

Best Wishes,
Chris Travers