Marketing Version: คืออะไร ความแตกต่างจาก Build Number และการกำหนดค่า

Marketing Version คืออะไร

Marketing Version คือสตริงเชิงความหมายที่แสดงเวอร์ชันของแอปพลิเคชันสำหรับผู้ใช้ปลายทาง ใน iOS กำหนดผ่านคีย์ CFBundleShortVersionString ใน Android กำหนดผ่าน versionName

คำว่า “Marketing Version” ถูกใช้อย่างเป็นทางการใน Xcode: ในอินเทอร์เฟซการตั้งค่า target ฟิลด์จะเรียกว่า “Marketing Version” และใน Info.plist จะสอดคล้องกับ CFBundleShortVersionString ใน Android สิ่งที่เทียบเท่าคือ versionName แม้ว่าคำนี้จะใช้น้อยกว่าก็ตาม

ตาม เอกสาร Apple Developer (2025) Marketing Version ต้องประกอบด้วยตัวเลขสูงสุดสามตัวคั่นด้วยจุด โดยไม่มีช่องว่างหรืออักขระพิเศษ แต่ละตัวต้องไม่เกิน 255

เลือก Marketing Version ของคุณให้สะท้อนถึงความสำคัญของการเปลี่ยนแปลง: การอัปเดตหลักสำหรับการเปลี่ยนแปลงที่สำคัญ การอัปเดตรองสำหรับฟังก์ชันใหม่

ความแตกต่างจาก Build Number ภายใน

Marketing Version แตกต่างโดยพื้นฐานจาก Build Number ในวัตถุประสงค์: อย่างแรกแจ้งผู้ใช้ อย่างที่สองระบุบิลด์สำหรับร้านค้า Build Number สามารถเพิ่มได้โดยไม่ต้องเปลี่ยน Marketing Version

ตัวอย่างเช่น เมื่อ แก้ไขข้อบกพร่องร้ายแรงในรุ่นที่เผยแพร่แล้ว ทีมสามารถสร้างแอปพลิเคชันใหม่ด้วย Marketing Version เดิม (1.2.0) แต่เพิ่ม Build Number (จาก 15 เป็น 16) ผู้ใช้จะเห็นเวอร์ชันเดียวกัน แต่ร้านค้าจะรู้ว่าบิลด์ใหม่กว่า

ความ ยืดหยุ่นนี้ช่วยให้นักพัฒนาสามารถเผยแพร่การแก้ไขโดยไม่ต้องแจ้งให้ผู้ใช้ทราบเกี่ยวกับการเปลี่ยนแปลงเวอร์ชัน

Marketing Version แสดงที่ไหน

Marketing Version ปรากฏในจุดปฏิสัมพันธ์สำคัญหลายจุดระหว่างผู้ใช้กับแอปพลิเคชัน ในร้านค้าแอป จะมองเห็นได้ในการ์ดแอป คำอธิบายการอัปเดต และประวัติเวอร์ชัน

บน อุปกรณ์ Marketing Version จะแสดงในการตั้งค่าระบบ (ส่วน “เกี่ยวกับ” หรือ “แอป”) ในกล่องโต้ตอบการอัปเดตผ่าน App Store หรือ Google Play และภายในแอปบนหน้าจอ “เกี่ยวกับ”

Marketing Version ที่ชัดเจนช่วยให้ผู้ใช้ประเมินความทันสมัยของเวอร์ชันที่ติดตั้งและตัดสินใจอัปเดต

Marketing Version บน iOS

บน iOS Marketing Version กำหนดใน Xcode ผ่านฟิลด์ “Marketing Version” ในแท็บ General ของการตั้งค่า target ค่าจะถูกบันทึกใน Info.plist เป็น CFBundleShortVersionString

รูปแบบเวอร์ชันถูก ควบคุมอย่างเข้มงวด โดย Apple: สตริงต้องมีตัวเลขหนึ่งถึงสามตัวคั่นด้วยจุด (เช่น 1, 1.2 หรือ 1.2.3) ความยาวสูงสุดคือ 18 อักขระ แต่ละตัวต้องไม่เกิน 255

ตาม แนวทางการตรวจสอบ App Store ของ Apple (2025) App Store Connect ไม่อนุญาตให้อัปโหลดบิลด์หาก Marketing Version แตกต่างจากเวอร์ชันที่เผยแพร่ก่อนหน้ามากกว่าหนึ่งค่าหลักหรือรอง — ซึ่งป้องกันผู้ใช้จากการพลาดการอัปเดต

ใช้ agvtool เพื่อจัดการ Marketing Version จาก command line — ช่วยลดความซับซ้อนในการรวม CI/CD และรับประกันการซิงโครไนซ์กับ Build Number

Marketing Version บน Android

บน Android Marketing Version กำหนดผ่านพารามิเตอร์ versionName ในไฟล์ build.gradle แตกต่างจาก iOS ตรงที่ Android ไม่ได้กำหนดข้อจำกัดที่เข้มงวดเกี่ยวกับรูปแบบสตริงเวอร์ชัน

versionName สามารถมีอักขระใดก็ได้: ตัวอักษร ตัวเลข ยัติภังค์ และจุด Google Play แสดงสตริงนี้ในการ์ดแอปและในรายการอัปเดต แต่ไม่ได้ตรวจสอบความถูกต้องกับรูปแบบใด ๆ

อย่างไรก็ตาม Google Play แนะนำให้ใช้รูปแบบเชิงความหมาย Major.Minor.Patch เพื่อความสอดคล้อง ซึ่งช่วยให้ผู้ใช้เข้าใจเวอร์ชันได้ง่ายขึ้นและช่วยให้วิเคราะห์การอัปเดตอัตโนมัติ

กำหนด versionName ที่สะท้อนประเภทของรุ่นอย่างชัดเจน — หลัก รอง หรือแพตช์ ซึ่งช่วยให้ผู้ใช้ประเมินความสำคัญของการเปลี่ยนแปลงได้อย่างรวดเร็ว

การสร้าง versionName แบบไดนามิก

versionName บน Android สามารถสร้างแบบไดนามิกตามแท็ก Git หรือตัวแปร CI/CD ซึ่งช่วยลดความซับซ้อนของกระบวนการกำหนดเวอร์ชันและขจัดความคลาดเคลื่อนระหว่างคลังและบิลด์

วิธีการทั่วไปคือการอ่าน แท็ก Git (เช่น v2.1.0) และใช้ค่าเป็น versionName หากไม่มีแท็ก สามารถสร้างเวอร์ชันตามวันที่และหมายเลข commit ได้

วิธีการนี้ รับประกันว่า versionName จะตรงกับสถานะของซอร์สโค้ดเสมอและไม่ต้องอัปเดตด้วยตนเอง

Marketing Version เทียบกับ Build Number

Marketing Version และ Build Number เป็นสองพารามิเตอร์อิสระที่ทำหน้าที่ต่างกัน Marketing Version แจ้งผู้ใช้ ในขณะที่ Build Number ระบุบิลด์ในทางเทคนิค

ความแตกต่างหลักคือ ความเป็นเอกลักษณ์ Build Number ต้องไม่ซ้ำกันสำหรับแต่ละบิลด์ Marketing Version สามารถซ้ำได้: หลายบิลด์ของเวอร์ชันเดียวกันมี Marketing Version เดียวกันแต่ Build Number ต่างกัน

ตาม นโยบาย Google Play (2025) หากคุณอัปโหลด APK สองไฟล์ที่มี Marketing Version เดียวกันแต่ Build Number ต่างกัน Google Play จะยอมรับทั้งสองเป็นบิลด์ที่แตกต่างกันของเวอร์ชันเดียวกัน กฎเดียวกันนี้ใช้กับ App Store

จำไว้: Build Number มีไว้สำหรับเครื่องจักร Marketing Version มีไว้สำหรับมนุษย์ ทำให้อย่างแรกเป็นอัตโนมัติและวางแผนอย่างหลังอย่างรอบคอบ

กลยุทธ์การกำหนดเวอร์ชัน

การเลือกกลยุทธ์ ขึ้นอยู่กับประเภทของแอปพลิเคชัน กลุ่มเป้าหมาย และกระบวนการเผยแพร่ สามรูปแบบหลัก — เชิงความหมาย ปฏิทิน และแบบผสม — ครอบคลุมสถานการณ์ส่วนใหญ่

การกำหนดเวอร์ชันเชิงความหมาย (SemVer) ใช้รูปแบบ Major.Minor.Patch และกำหนดอย่างเข้มงวดว่าเมื่อใดควรเพิ่มแต่ละองค์ประกอบ เหมาะสำหรับแอปพลิเคชันที่มี API สาธารณะและการรวมที่ซับซ้อน

ตาม semver.org (2023) เวอร์ชัน 2.0.0 ของข้อกำหนด SemVer ถูกใช้ใน 89% ของโปรเจกต์มือถือแบบโอเพนซอร์สและรองรับโดยผู้จัดการแพ็กเกจทั้งหมด

การกำหนดเวอร์ชันตามปฏิทิน

การกำหนดเวอร์ชันตามปฏิทิน (CalVer) ใช้วันที่เผยแพร่เป็นเวอร์ชัน — เช่น 25.06 สำหรับเดือนมิถุนายน 2025 วิธีการนี้เป็นที่นิยมในแอปพลิเคชันที่มีการอัปเดตบ่อยครั้ง

CalVer ไม่ได้สื่อข้อมูลเกี่ยวกับความสำคัญของการเปลี่ยนแปลง แต่แสดงความใหม่ของเวอร์ชันอย่างชัดเจน ผู้ใช้เข้าใจทันทีว่าเวอร์ชัน 25.06 ใหม่กว่า 25.03

เลือกการกำหนดเวอร์ชันตามปฏิทินหากแอปของคุณอัปเดตบ่อยครั้งและผู้ใช้ใส่ใจกับความสดใหม่ของข้อมูลมากกว่าขอบเขตของการเปลี่ยนแปลง

คำแนะนำในการเลือก

สำหรับ MVP และสตาร์ทอัป เวอร์ชันเชิงความหมายแบบง่ายไม่มีแพตช์ (Major.Minor) เหมาะสม สำหรับผลิตภัณฑ์ที่โตเต็มที่พร้อมการสนับสนุนระยะยาว — SemVer เต็มรูปแบบ สำหรับแอปที่มีการเผยแพร่ต่อเนื่อง — CalVer

ห้ามใช้วันที่เป็น Build Number — อาจทำให้เกิดข้อขัดแย้งเมื่อมีหลายบิลด์ต่อวัน Build Number ควรเป็นลำดับหรือแบบประกอบ แต่เพิ่มขึ้นแบบโมโนโทนิกเสมอ

ข้อผิดพลาดทั่วไปกับ Marketing Version

ข้อผิดพลาดทั่วไป คือการข้ามองค์ประกอบเวอร์ชันเมื่อย้ายไปยังสายหลักใหม่ ตัวอย่างเช่น หลังจากเวอร์ชัน 1.9.9 เวอร์ชันถัดไปควรเป็น 2.0.0 ไม่ใช่ 1.10.0 ซึ่งทำลายความหมายและทำให้ผู้ใช้สับสน

ปัญหาทั่วไปอีกประการคือความไม่ตรงกันระหว่าง Marketing Version ในโค้ดและในร้านค้าแอป ตรวจสอบเสมอว่า versionName ใน build.gradle ตรงกับเวอร์ชันที่ระบุใน Google Play Console หรือ App Store Connect ก่อนส่งบิลด์เพื่อตรวจสอบ

ตัวอย่างการตั้งค่า Marketing Version

ตัวอย่างโค้ด แสดงวิธีตั้งค่า Marketing Version บนทั้งสองแพลตฟอร์มและทำให้การอัปเดตเป็นอัตโนมัติ

การตั้งค่า versionName ใน Android Gradle

ใน Android versionName ถูกกำหนดใน build.gradle ค่าสามารถเป็นแบบคงที่หรืออ่านจากตัวแปรสภาพแวดล้อม

android {
    defaultConfig {
        versionCode 15
        versionName "2.1.0"
    }
}

// อ่านเวอร์ชันจากแท็ก Git
def getVersionNameFromGit = {
    def tag = "git describe --tags".execute().
        text.trim()
    return tag.startsWith("v") ? tag.substring(1) : tag
}

versionName ถูกดึงมาจากแท็ก Git เพื่อให้แน่ใจว่าสอดคล้องระหว่างเวอร์ชันในคลังและแอปพลิเคชันที่สร้างขึ้น

การจัดการ Marketing Version ใน Xcode

บน iOS Marketing Version กำหนดผ่าน Xcode หรือ agvtool คำสั่งด้านล่างตั้งค่าเวอร์ชันการตลาดใหม่

# ตั้งค่า Marketing Version
xcrun agvtool new-marketing-version 2.1.0

# เพิ่มอัตโนมัติ
xcrun agvtool next-marketing-version

agvtool อัปเดต Info.plist โดยอัตโนมัติและซิงโครไนซ์เวอร์ชันทั่วทุก target ของโปรเจกต์ Xcode

Fastlane สำหรับทั้งสองแพลตฟอร์ม

Fastlane ช่วยให้จัดการ Marketing Version บนทั้งสองแพลตฟอร์มจากสคริปต์เดียว ทำให้การบำรุงรักษาโปรเจกต์ข้ามแพลตฟอร์มง่ายขึ้น

# ตั้งค่าเวอร์ชันการตลาด
increment_version_number(
    version_number: "2.1.0"
)

# เพิ่มเวอร์ชันรองอัตโนมัติ
increment_version_number(
    bump_type: "minor"
)

Fastlane ทำงานบนทั้งสองแพลตฟอร์มและรองรับโดยบริการ CI/CD ส่วนใหญ่