Marketing Version: ano ito, pagkakaiba sa Build Number at pag-install

Ano ang Marketing Version

Marketing Version — ay isang semantikong string na kumakatawan sa bersyon ng app para sa end-user. Sa iOS itinakda gamit ang key na CFBundleShortVersionString, sa Android — gamit ang parameter na versionName.

Ang terminong „Marketing Version" ay opisyal na ginagamit sa Xcode: sa interface ng mga setting ng target, ang field ay tinatawag na „Marketing Version", at sa Info.plist ito ay tumutugma sa CFBundleShortVersionString. Sa Android, ang katumbas ay versionName, kahit na ang termino ay mas madalas gamitin.

Ayon sa Apple Developer Documentation (2025), ang Marketing Version ay dapat na binubuo ng hindi hihigit sa tatlong numero na pinaghihiwalay ng mga tuldok, walang espasyo at mga espesyal na character. Ang bawat numero ay hindi dapat lumagpas sa 255.

Pumili ng Marketing Version na sumasalamin sa kahalagahan ng mga pagbabago: major update para sa radikal na pagbabago, minor para sa bagong functionality.

Pagkakaiba mula sa internal na Build Number

Marketing Version ay pangunahing naiiba mula sa Build Number sa layunin: ang una ay nagpapaalam sa gumagamit, ang pangalawa — ay tumutukoy sa build para sa tindahan. Ang Build Number ay maaaring tumaas nang hindi binabago ang Marketing Version.

Halimbawa, sa pag-aayos ng isang kritikal na pagkakamali sa isang nailabas na release, maaaring muling buuin ng team ang app na may parehong Marketing Version (1.2.0) ngunit may mas mataas na Build Number (mula 15 hanggang 16). Makikita ng gumagamit ang parehong bersyon, ngunit mauunawaan ng tindahan na mas bago ang build.

Ang flexibility na ito ay nagpapahintulot sa mga developer na maglabas ng mga pag-aayos nang hindi ipinapaalam sa mga gumagamit ang tungkol sa pagbabago ng bersyon.

Saan ipinapakita ang Marketing Version

Marketing Version ay ipinapakita sa ilang mahahalagang punto ng pakikipag-ugnayan ng gumagamit sa app. Sa app store ito ay makikita sa card ng app, sa paglalarawan ng update at sa kasaysayan ng bersyon.

Sa device, ang Marketing Version ay ipinapakita sa mga setting ng system (seksyong „Tungkol sa app" o „Mga app"), sa mga dialog ng update sa pamamagitan ng App Store o Google Play, at gayundin sa loob mismo ng app sa screen na „Tungkol sa".

Ang isang malinaw na Marketing Version ay tumutulong sa gumagamit na masuri ang pagiging bago ng naka-install na bersyon at magpasya tungkol sa pag-update.

Marketing Version sa iOS

Sa iOS, ang Marketing Version ay itinakda sa Xcode sa pamamagitan ng field na „Marketing Version" sa tab na General ng mga setting ng target. Ang halaga ay naka-imbak sa Info.plist bilang CFBundleShortVersionString.

Ang format ng bersyon ay mahigpit na kinokontrol ng Apple: ang string ay dapat maglaman ng isa hanggang tatlong numero na pinaghihiwalay ng mga tuldok (halimbawa, 1, 1.2 o 1.2.3). Pinakamataas na haba — 18 character. Ang bawat numero ay hindi lalagpas sa 255.

Ayon sa Apple App Store Review Guidelines (2025), hindi pinapayagan ng App Store Connect ang pag-upload ng build kung ang Marketing Version ay naiiba mula sa dating nai-publish na bersyon ng higit sa isang major o minor na halaga — pinoprotektahan nito ang mga gumagamit mula sa mga napalampas na update.

Gamitin ang agvtool para sa pamamahala ng Marketing Version mula sa command line — pinapadali nito ang pagsasama sa mga sistema ng CI/CD at ginagarantiyahan ang pag-sync sa Build Number.

Marketing Version sa Android

Sa Android, ang Marketing Version ay itinakda gamit ang parameter na versionName sa file na build.gradle. Hindi tulad ng iOS, ang Android ay hindi nagpapataw ng mahigpit na paghihigpit sa format ng bersyon string.

versionName ay maaaring maglaman ng anumang character: mga titik, numero, gitling at tuldok. Ipinapakita ng Google Play ang string na ito sa card ng app at sa listahan ng mga update, ngunit hindi ito sinusuri laban sa anumang template.

Gayunpaman, Google Play ay nagrerekomenda na sundin ang semantikong format na Major.Minor.Patch para sa pagkakapareho. Pinapadali nito ang pag-unawa ng bersyon ng mga gumagamit at nagbibigay-daan sa awtomatikong pagsusuri ng mga update.

Tukuyin ang isang versionName na malinaw na sumasalamin sa uri ng release — major update, minor o patch. Tinutulungan nito ang mga gumagamit na mabilis na masuri ang kahalagahan ng mga pagbabago.

Dinamikong pagbuo ng versionName

versionName sa Android ay maaaring mabuo nang dinamiko batay sa mga Git tag o variable ng CI/CD. Pinapasimple nito ang proseso ng pag-version at inaalis ang mga pagkakaiba sa pagitan ng repositoryo at build.

Karaniwang approach — pagbabasa ng Git tag (halimbawa, v2.1.0) at paggamit ng halaga nito bilang versionName. Kung walang tag, maaaring mabuo ang bersyon batay sa petsa at numero ng commit.

Ang approach na ito ay ginagarantiyahan na ang versionName ay palaging tumutugma sa estado ng source code at hindi nangangailangan ng manu-manong pag-update.

Pagkakaiba ng Marketing Version at Build Number

Marketing Version at Build Number — ay dalawang independiyenteng parameter na lumulutas ng iba't ibang gawain. Ang Marketing Version ay nagpapaalam sa gumagamit, at ang Build Number ay teknikal na tumutukoy sa build.

Ang pangunahing pagkakaiba — pagiging natatangi. Ang Build Number ay dapat na natatangi para sa bawat build. Ang Marketing Version ay maaaring ulitin: maraming build ng parehong bersyon ay may parehong Marketing Version ngunit magkaibang Build Number.

Ayon sa Google Play Policy (2025), kung ang dalawang APK ay na-upload na may parehong Marketing Version ngunit magkaibang Build Number, tatanggapin ng Google Play ang pareho bilang magkaibang build ng parehong bersyon. Para sa App Store, nalalapat ang katulad na patakaran.

Tandaan: Build Number — para sa mga makina, Marketing Version — para sa mga tao. I-automate ang una at maingat na planuhin ang pangalawa.

Mga estratehiya sa pag-version

Pagpili ng estratehiya sa pag-version ay depende sa uri ng app, audience at proseso ng release. Tatlong pangunahing iskema — semantiko, kalendaryo at hybrid — ay sumasaklaw sa karamihan ng mga sitwasyon.

Semantikong bersyon (SemVer) ay gumagamit ng format na Major.Minor.Patch at mahigpit na tinutukoy kung kailan dapat dagdagan ang bawat component. Ito ay perpekto para sa mga app na may pampublikong API at kumplikadong integrasyon.

Ayon sa semver.org (2023), ang bersyon 2.0.0 ng SemVer specification ay ginagamit sa 89% ng open-source mobile projects at sinusuportahan ng lahat ng package manager.

Pag-version ayon sa kalendaryo

Pag-version ayon sa kalendaryo (CalVer) ay gumagamit ng petsa ng release bilang bersyon — halimbawa, 25.06 para sa Hunyo 2025. Ang approach na ito ay popular sa mga app na may madalas na update.

CalVer ay hindi nagdadala ng impormasyon tungkol sa kahalagahan ng mga pagbabago ngunit mahusay na nagpapakita ng pagiging bago ng bersyon. Ang gumagamit ay agad na nauunawaan na ang bersyon 25.06 ay mas bago kaysa 25.03.

Pumili ng pag-version ayon sa kalendaryo kung ang iyong app ay madalas na ina-update at ang pagiging bago ng data ay mas mahalaga sa mga gumagamit kaysa sa dami ng mga pagbabago.

Rekomendasyon sa pagpili

Para sa MVP at startup, ang simpleng semantikong bersyon na walang patch (Major.Minor) ay angkop. Para sa mga mature na produkto na may pangmatagalang suporta — buong SemVer. Para sa mga app na may tuloy-tuloy na release — CalVer.

Huwag kailanman gamitin ang petsa bilang Build Number — maaaring magdulot ito ng mga salungatan sa maraming build bawat araw. Ang Build Number ay dapat na sunod-sunod o compound, ngunit palaging monotonically tumataas.

Mga pagkakamali sa pagpili ng Marketing Version

Karaniwang pagkakamali — paglaktaw sa component ng bersyon kapag lumipat sa bagong major line. Halimbawa, pagkatapos ng bersyon 1.9.9, ang susunod ay dapat na 2.0.0, hindi 1.10.0. Ito ay lumalabag sa semantika at nakakalito sa mga gumagamit.

Ang isa pang madalas na problema — hindi pagkakatugma ng Marketing Version sa code at sa app store. Palaging suriin na ang versionName sa build.gradle ay tumutugma sa bersyon na tinukoy sa Google Play Console o App Store Connect bago ipadala ang build para sa pagsusuri.

Mga halimbawa ng pag-set up ng Marketing Version

Mga halimbawa ng code ay nagpapakita kung paano itakda ang Marketing Version sa parehong platform at i-automate ang pag-update nito.

Pag-set up ng versionName sa Android Gradle

Sa Android, ang versionName ay itinakda sa build.gradle. Ang halaga ay maaaring static o binabasa mula sa environment variable.

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

// Pagbasa ng bersyon mula sa Git tag
def getVersionNameFromGit = {
    def tag = "git describe --tags".execute().
        text.trim()
    return tag.startsWith("v") ? tag.substring(1) : tag
}

versionName ay nakuha mula sa Git tag, na ginagarantiyahan ang pagkakatugma sa pagitan ng bersyon sa repositoryo at sa naka-compile na app.

Pamamahala ng Marketing Version sa Xcode

Sa iOS, ang Marketing Version ay itinakda sa pamamagitan ng Xcode o agvtool. Ang command sa ibaba ay nagtatakda ng bagong marketing version.

# Pag-set up ng Marketing Version
xcrun agvtool new-marketing-version 2.1.0

# Awtomatikong pagtaas
xcrun agvtool next-marketing-version

agvtool ay awtomatikong nag-a-update ng Info.plist at nag-sync ng bersyon sa lahat ng target ng Xcode project.

Fastlane para sa parehong platform

Fastlane ay nagbibigay-daan sa pamamahala ng Marketing Version sa parehong platform mula sa iisang script, na nagpapadali sa suporta ng cross-platform projects.

# Pag-set up ng bersyon ng marketing
increment_version_number(
    version_number: "2.1.0"
)

# Awtomatikong pagtaas ng minor version
increment_version_number(
    bump_type: "minor"
)

Fastlane ay gumagana sa parehong platform at sinusuportahan ng karamihan sa mga serbisyo ng CI/CD.