Re: Proposal to formalize end-of-life

On Sun, Dec 30, 2012 at 3:11 AM, Erik Huelsmann <..hidden..> 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