On Sun, Dec 30, 2012 at 3:11 AM, Erik Huelsmann <[email protected]> wrote:
> Hi,
>
> In an attempt to create clarity for our users, I'd like to add an
> end-of-life statement to the ledgersmb.org website. However, I'm not sure
> we currently have consensus of the end-of-life criteria.
>
> My proposal would be that:
>
> 1.0 and 1.1 have been EOL'd by the release of 1.2.
> 1.2 will be EOL'd by the release of 1.4
> 1.3 and up will be EOL'd when the distributions (known to us) in which
> they're packaged will be EOL'd
>
> 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?
>
One big issue is that if we ever get in RHEL (and I think we should aim for
that), we are going to have very long support cycles indeed. Red Hat ends
up supporting PostgreSQL versions for a year after they are EOL'd. I
think there is a certain point where the distro gets to take on some
responsiblity of a long support cycle, and I think this is especially true
if it is a vendor which makes money off such guarantees (and indeed Red Hat
pays people to maintain such packages). Another point is that near the end
of the life of those distros,
I think a bigger issue actually is ensuring that every community-supported
version of PostgreSQL is supported. This makes it possible for those on
more conservative distros to use our software. Right now this isn't an
issue. LedgerSMB 1.3 supports all supported versions, and it is likely
that in the hext year LedgerSMB 1.4 will too. But if 1.5 requires
PostgreSQL 9.1, this means we need at least 1.4 (and maybe 1.3 since it is
in LTS distros) until 9.0 is no longer supported. So I would like to see
this as a major factor in the decision to support older branches.
I would also like to suggest that we be a lot more selective about
backporting fixes to supported branches older than the newest stable
branch. My thinking here is that while the newest stable branch may have
unexpected workflow issues as we may want a fair bit of flexibility in
fixing. However folks using older stable branches can be assumed to be
highly invested in that workflow and we need to defer to that as much as
possible. Does this sound reasonable?
>
> Best Wishes,
Chris Travers
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
