Oh, I see. We would have to modify the community code to include a call to syslog(3), but I don't see that as too much of a problem.
I think the biggest issue is, for S10, this can only be issued in a patch. So we're relying on people who don't read release notes to keep up to date with the latest patches. Therefore there's a good chance that no one will ever see the syslog message, but since it's technically feasible to do, we will do it. John Fischer wrote: > James, > > The application warning message would be from the previous > release. So you would need to patch an application or applications > with the message for Solaris 10. This should occur at the > same time as the release notes are updated. The reason why > this is desirable is because many of the those using the > product might not even see the release notes or read a > man page. That is why the EOF procedures document found > at: > > http://sac.sfbay/cgi-bin/bp.cgi?NAME=Obsolete-EOF.bp > > suggests: > > Where technically feasible, inclusion in the release > where the interface is declared Obsolete of a warning > mechanism if the interface is used. > > It goes on to suggest a log warning could be used. > > So in the Patch release of Solaris where the release note > will be updated it would be really good and if technically > feasible to also have a mechanism for the EOF message to > be declared automatically. When I've Obsoleted an interface > I have done a popup dialog because I deal with GUIs. However, > in this case a system log or to standard error would be sufficient. > > Thanks, > > John > > On Thu, 2008-10-02 at 07:14, James Gates wrote: >> 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. >>> >> That makes sense. We can even include in the message a reference to our >> upgrade tool. >>> Also is there a command that should spit out the same >>> message? >> We hadn't planned to do this. >> >> All the 8.2 binaries are found in /usr/postgres/8.2/bin. I had >> anticipated that this would no longer exist after an upgrade, since all >> 8.2 packages will be removed. >> >> There are 3 popular commands in /usr/postgres/8.2/bin that a user would >> call to create, start or connect to a PostgreSQL database. >> >> I suppose when we remove the 8.2 packages from Nevada, we could add 3 >> scripts to /usr/postgres/8.2/bin in the 8.3 packages that print the >> above message. And when we EOF 8.3, add similar scripts to 8.4, etc. >>> 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 > -- Jim Gates Sun Microsystems Nashua, NH, USA http://sun.com/postgresql
