先不論何種做法
正常公司轉換版本時
推出新版本舊版本會支援一定的時間
過了時間後就不support了
也就是按照正常流程來看
現在直接做一個v3版本
推薦尚未開發的使用者使用
v2版本幫忙做個更新
讓已開發使用者有時間做版本轉換
到一定時間後公告不更新自求多福
時間多久就看自己有多閒了
※ 引述《shter (飛梭之影)》之銘言：
: 先感謝之前 PO 在這邊後得到不少板友的意見
: 5/7 時交通部 PTX 通知台鐵升級 v3 版 API
: 這下可不得了，它升級後把車站代碼全換了一套
: {id:"1001", v3id:"0900", name: "基隆"},
: {id:"1005", v3id:"0960", name: "汐止"},
: {id:"1031", v3id:"0970", name: "汐科"},
: {id:"1006", v3id:"0980", name: "南港"},
: {id:"1007", v3id:"0990", name: "松山"},
: {id:"1008", v3id:"1000", name: "台北"},
: .
: .
: .
: id 是舊版，v3id 是新版
: 新舊版都是數字，都是四碼，有重複的號碼，目前無從自動判斷
: 原本用車站代碼來當索引寫的程式全部要重改
: 現在我先製作了轉換車站代碼的兩個程式
: rocptx.tra.v2Sv3("1008") //執行完會得到 "1000" 將台北站代碼轉成 v3 版
: rocptx.tra.v3Sv2("0990") //執行完會得到 "1007" 將松山站代碼轉成 v2 版
: 然後暫時把 v3 版的 Function 放在 rocptx.tra.v3 底下呼叫
: 可以先用 v2Sv3 把舊版車站代碼轉成新版後傳入 v3 的 Function 內
: 再將收到的 StationID 用 v3Sv2 轉回舊版 id 讓原本的程式使用
: 想請教板友，通常遇到這種資料源把用來當索引的代碼全部大改時
: 在 library 這邊開發會怎麼處理?
: 1. library 維持全用舊的代碼呼叫，底層實作時再全部進行轉換，收到的回應內容
: 也把 StationID 全部轉成舊版代碼再 return 給呼叫者
: 這樣用戶完全不需要改 code 可以無痛升級繼續用 v3 API
: 2. library 分成 v2 跟 v3 切開來，車站列表資料即使內容相同只有 id 不同
: 也要建立兩份，然後只提供 id 轉換 Function，讓用戶自己呼叫的時候
: 用轉換 Function 把 id 轉成對應 v2 或 v3 版的
: 也就是舊版不動，新版要用自己把所有車站代碼轉換後呼叫新版 v3 Function
: 3. library 跟著 API 升級，把所有車站代碼都換成新的，強制用戶跟著重寫 code
: 所有用 v2 代碼操作的 code 都要過 v2Sv3 的 Function 轉換後才能正常操作
: 尷尬的是 PTX 這邊 v3 版車站代碼改了
: 可是台鐵提供的固定時刻表資料 XML 及 JSON 仍然用的是舊版代碼
: 所以要操作離線查詢(從 JSON 檔中查時刻表)只能用舊版代碼
: 另外目前有些車站(如彰化)在 v3 API 線上查不到車站資料，已回報請官方修復
: 有需要操作或玩 v3 版 API 者請更新 dist 內的 ptx.js 或 ptx.min.js
: https://github.com/melixyen/rocptx