Yes, but we're working with them to help migrate. We can't remove 8.1 from Nevada until 1 year after EOF announcement, or until SunMC have migrated (whichever is sooner).
Also, our EOL policy for PostgreSQL provides 5.5 years of support following EOL announcement (6 months grace, 2 years phase 1, 3 years phase 2). So SunMC can continue to use 8.1 on S10 for some time. Bill Walker wrote: > > Just curious, but isn't SunMC still using 8.1.4? Are plans in place > over there to use the same version/packages? > > bill. > > > John Fischer wrote: >> James, >> >> Sounds like a well thought out plan. >> Does it make sense to add to the release note which version is >> recommended to migrate to in the future release? So perhaps the >> release note might say something like: >> >> PostgreSQL version 8.2 may no longer be supported in a future >> release of Solaris. You may want to migrate to PostgresSQL >> version 8.4. >> >> Also is there a command that should spit out the same >> message? >> >> Thanks, >> >> John >> >> >> On Tue, 2008-09-30 at 15:15, James Gates wrote: >>> I'm sponsoring this on behalf of the PostgreSQL P-Team. Timeout is >>> set for 8th October. Attached is a copy of the proposal, which can >>> also be found in the case directory. >>> >>> -- >>> Jim Gates Sun Microsystems >>> Nashua, NH, USA http://sun.com/postgresql >>> >>> ______________________________________________________________________ >>> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >>> Copyright 2007 Sun Microsystems >>> >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> EOF of PostgreSQL 8.2 in Solaris >>> >>> 1.2. Name of Document Author/Supplier: >>> James Gates >>> >>> 1.3. Date of This Document: >>> 09/30/08 >>> >>> 1.3.1. Date this project was conceived: >>> 09/17/08 >>> >>> 1.4. Name of Major Document Customer(s)/Consumer(s): >>> 1.4.1. The PAC or CPT you expect to review your project: >>> >>> Database PAC >>> >>> 1.4.2. The ARC(s) you expect to review your project: >>> >>> LSARC >>> >>> 1.4.3. The Director/VP who is "Sponsoring" this project: >>> >>> Chris.Armes at sun.com >>> >>> 1.4.4. The name of your business unit: >>> >>> Software/RPE >>> >>> 1.5. Email Aliases: >>> 1.5.1. Responsible Manager: Thulasinathan.P at sun.com >>> 1.5.2. Responsible Engineer: James.Gates at sun.com >>> 1.5.3. Marketing Manager: Wei-Chen.Chiu at sun.com >>> 1.5.4. Interest List: sun-postgres-pteam at sun.com >>> >>> [In the following, "8.1", "8.2", "8.3" or "8.4" without qualification >>> refer to the corresponding PostgreSQL version.] >>> >>> 2. Project Summary >>> 2.1. Project Description: >>> >>> Solaris currently includes versions 8.1, 8.2 & 8.3. It is expected >>> that the community will release 8.4 in Dec 2008. We plan to >>> integrate >>> it into Solaris shortly after community release. >>> >>> This project proposes to announce the EOF for 8.2 in a patch >>> release of Solaris (i.e. Solaris 10 Update) and removal of the >>> feature in a minor release of Solaris (i.e. Solaris 11). >>> >>> The intention of the PostgreSQL EOL policy approved by the DB PAC >>> is to provide active support for the latest 2 versions integrated >>> with Solaris. Hence the release and integration of 8.4 triggers the >>> EOF & EOL of 8.2. >>> >>> Note that the ARC case to EOF 8.1 was approved on 01/15/2008 >>> (LSARC/2008/005). >>> >>> 2.2. Risks and Assumptions: >>> >>> If Solaris 11 is shipped without 8.2 it would force customers >>> still running this version to upgrade PostgreSQL immediately >>> if they upgrade their O/S. They might even decide not to >>> upgrade because of this (although I think this is unlikely). >>> Those customers who must continue to run 8.2 can still visit the >>> community website and download the freely available software. >>> >>> There is also a risk that some other Sun products depend on >>> 8.2; we need to ensure that these are upgraded to at least 8.3. >>> I have verified that no other packages in the SFWNV >>> consilidation are listed as depending on any of the PostgreSQL >>> 8.2 packages. >>> >>> 3. Business Summary >>> >>> 3.1. Problem Area: >>> >>> The PostgreSQL community release a new major version approximately >>> once every year. For various reasons, we need to encourage customers >>> to upgrade to newer versions when they become available. >>> >>> 3.2. Market/Requester: >>> >>> PostgreSQL P-Team >>> >>> 3.3. Business Justification: >>> >>> We want to reduce the amount of resources needed to support >>> and sustain >>> old versions of PostgreSQL. We also want to keep in sync with >>> the >>> PostgreSQL communitys EOL policy i.e. we don't want to >>> be in the position of having a PostgreSQL version in Solaris that is >>> no longer supported and maintained by the community. >>> >>> 3.4. Competitive Analysis: >>> >>> N/A >>> >>> 3.5. Opportunity Window/Exposure: >>> >>> This needs to coincide with the integration of 8.4, so as to >>> ensure >>> that only the latest 2 versions of PostgreSQL are >>> available/supported, >>> and all previous versions are EOF/EOL. >>> >>> 3.6. How will you know when you are done?: >>> >>> The project will be complete when the announcement is made in >>> a patch release of Solaris and when 8.2 is removed from a minor >>> release of Solaris. >>> >>> 4. Technical Description: >>> 4.1. Details: >>> >>> This project will create a release note in a Patch release of >>> Solaris (i.e. Solaris 10 Update). It will also remove all 8.2 >>> packages from a Minor release of Solaris (i.e., Solaris 11). >>> >>> The Solaris 10 Update Release Notes will be updated with the >>> following text: >>> >>> PostgreSQL version 8.2 may no longer be supported in >>> a future release. >>> 4.2. Bug/RFE Number(s): >>> >>> N/A >>> 4.3. In Scope: >>> >>> 4.4. Out of Scope: >>> 4.5. Interfaces: >>> >>> Imported Interfaces: >>> Interface Stability Citation >>> --------- --------- ---------- >>> N/A >>> >>> Exported Interfaces: >>> Interface Classification Comments >>> --------------------- --------------- >>> ------------------------ >>> SUNWpostgr-82-client Obsolete Package >>> SUNWpostgr-82-contrib Obsolete Package >>> SUNWpostgr-82-devel Obsolete Package >>> SUNWpostgr-82-docs Obsolete Package >>> SUNWpostgr-82-jdbc Obsolete Package >>> SUNWpostgr-82-libs Obsolete Package >>> SUNWpostgr-82-pl Obsolete Package >>> SUNWpostgr-82-server Obsolete Package >>> SUNWpostgr-82-server-data-root Obsolete Package >>> SUNWpostgr-82-tcl Obsolete Package >>> /lib/svc/method/postgresql Obselete SMF method script >>> /usr/postgres/8.2 Obsolete Installation location >>> /usr/postgres/8.2/bin Obsolete Executable location >>> /usr/postgres/8.2/doc Obsolete Documentation >>> /usr/postgres/8.2/etc Obsolete Config files >>> /usr/postgres/8.2/include Obsolete Header files >>> /usr/postgres/8.2/jdbc Obsolete JDBC driver >>> /usr/postgres/8.2/lib Obsolete Shared libraries >>> /usr/postgres/8.2/man Obsolete Manual pages >>> /usr/postgres/8.2/share Obsolete Localized message files >>> /usr/share/man/man5/postgres_82.5 Obselete Sun specific man >>> page >>> /var/postgres/8.2 Obselete Default db location >>> /var/svc/manifest/application/database/postgresql.xml >>> Obselete SMF manifest file >>> >>> Also deleted are all files under /usr/postgres/8.2/* (too >>> numerous to >>> list here). >>> >>> 4.6. Doc Impact: >>> >>> Comprehensive documentation was included with the product. This will >>> be removed. The only other documentation impact will be the delivery >>> of the release note (see section 4.1). >>> >>> 4.7. Admin/Config Impact: >>> >>> None. >>> 4.8. HA Impact: >>> >>> N/A >>> 4.9. I18N/L10N Impact: >>> >>> N/A >>> 4.10. Packaging & Delivery: >>> >>> The packages listed in 4.5 will be deleted and will not be >>> included with the first release of Solaris 11. However, note >>> that they have been delivered with SXDE; I don't know if this >>> will require us to go through the full EOF process. >>> >>> Users upgrading from Solaris 10 who are running a database >>> under PostgreSQL 8.1 or 8.2 will have to use the upgrade >>> solution we >>> included with the 8.3 integration to upgrade to 8.3 or 8.4. >>> >>> 4.11. Security Impact: >>> >>> No impact. >>> 4.12. Dependencies: >>> >>> Depends on the integration of 8.4 >>> >>> 5. Reference Documents: >>> >>> All material associated with the original ARC case to integrate >>> PostgreSQL 8.1 can be found at: >>> http://sac.sfbay.sun.com/LSARC/2005/515/ >>> >>> Material associated with the ARC case to integrate PostgreSQL >>> 8.2 can be found at: >>> http://sac.sfbay.sun.com/LSARC/2006/655/ >>> >>> Material associated with the ARC case to integrate PostgreSQL >>> 8.3 can be found at >>> http://sac.sfbay.sun.com/LSARC/2008/004 >>> >>> PostgreSQL 8.3 information can be found at: >>> http://www.postgresql.org/ >>> >>> 6. Resources and Schedule: >>> 6.1. Projected Availability: >>> >>> Can be done immediately after 8.4 is integrated. >>> >>> 6.2. Cost of Effort: >>> >>> Minimal; just removal of a component. >>> >>> 6.3. Cost of Capital Resources: >>> >>> None. >>> >>> 6.4.1. Consolidation or Component Name: >>> >>> SFW >>> >>> 6.4.3. Type of CPT Review and Approval expected: >>> >>> FastTrack >>> >>> 6.4.4. Project Boundary Conditions: >>> >>> N/A >>> >>> 6.4.5. Is this a necessary project for OEM agreements: >>> >>> No >>> >>> 6.4.6. Notes: >>> >>> 6.4.7. Target RTI Date/Release: >>> >>> ASAP after the community releases 8.4. >>> >>> 6.4.8. Target Code Design Review Date: >>> 6.4.9. Update approval addition: >>> >>> 6.5. ARC review type: >>> >>> FastTrack >>> >>> 6.6. ARC Exposure: >>> >>> open >>> >>> 6.6.1. Rationale: >>> >>> N/A >>> >>> 7. Prototype Availability: >>> 7.1. Prototype Availability: >>> >>> N/A >>> >>> 7.2. Prototype Cost: >>> >>> N/A >> > -- Jim Gates Sun Microsystems Nashua, NH, USA http://sun.com/postgresql
