shape_RMS - Online sa Cloud

PROGRAMA:

NAME

shape_RMS - Panimula sa shapeTools Release Management System

SINOPSIS

hugis rms - ipakita ang buod ng shapeTools Release Management System Functions

DESCRIPTION

Ang shapeTools Bitawan pamamahala Sistema (shape_RMS) tumutulong sa pagbuo at pagsubaybay
ng mga paglabas ng system sa mga kumplikadong (multi programmer) na mga proyekto sa pagbuo ng software. Ito
introductory manual page ay nagbibigay ng pangkalahatang-ideya ng shape_RMS functionality at tumutulong
pagsisimula sa release management system. Kapag binabasa ang panimula na ito, ikaw
dapat ay pamilyar sa mga pangunahing kaalaman ng shapeTools version control system at ang
shape configuration management program, o dapat ay mayroon kang shapeTools version control
at ang hugis(1) manual na mga pahina sa kamay. Komplementaryo sa maikling pahina ng manu-manong sanggunian,
mayroong isang tutorial na panimula sa paggamit ng shapeTools, na nagpapaliwanag kung paano ipakilala
at gamitin ang functionality ng shape-toolkit nang matalino sa isang multi programmer na proyekto.

Ang pakikipagtulungan at pagpapalabas ng modelo ng pamamahala ng isang software development project ay mataas
depende sa likas na katangian ng proyekto. Mga salik tulad ng programming language na ginamit, ang
laki ng pangkat ng programmer, ang likas na katangian ng binuong software, o mga lokal na kagustuhan
malakas na nakakaimpluwensya sa modelong ito. Ang sistema ng pamamahala ng paglabas na kasalukuyang ipinapatupad,
ay sa karamihan ng mga kaso ay hindi magkasya lahat ang mga pangangailangan mo. Kunin ito bilang isang prototype upang magsimula at subukan
upang ibagay ito ng paunti-unti. Sa kasalukuyang estado, binabago ang pamamahala ng release
system ay nangangailangan ng mahusay na mga kasanayan sa Makefile at Shapefile pagsulat at maraming pasensya. Isipin mo
dalawang beses tungkol sa bawat pagbabago na iyong ginagawa! Pagtatatag ng magandang kooperasyon at pagpapalaya
ang modelo ay hindi kasingdali ng maaaring hitsura nito sa unang tingin.

Ang shapeTools RMS ay nagpapataw ng isang pangkalahatang frame para sa istraktura ng proyekto at ang pagbuo
proseso sa loob ng isang software development project. Ang frame na ito ay kinakailangan para sa paglabas
sistema ng pamamahala upang matukoy ang mga workpiece nito at upang sistematikong makapagdokumento
ang ebolusyon ng mga pagsasaayos ng system. Tinutulungan nito ang developer na magkaroon ng lahat ng system
pagsasaayos at pagbuo ng mga aksyon na awtomatikong ginawa, upang siya ay makapag-concentrate sa
kanyang gawain sa pagpapaunlad, sa halip na mga aktibidad sa pamamahala ng code.

Ang lahat ng mga function ng shapeTools RMS ay ginagampanan ng hugis(1) programa. Ito
binibigyang-kahulugan ang isang file ng paglalarawan (ang Shapefile) at ginagawa ang pagkilos na nauugnay sa a
target na pangalan na ibinigay kasama ang tawag sa hugis. Karaniwan, maaari kang magsagawa ng isang grupo ng macro
mga kahulugan kasama ang tawag sa hugis. Ino-overwrite ng mga kahulugang ito ang panloob na default
mga setting ng macro. Samakatuwid, ang mga tawag ng shape_RMS ay may pangkalahatang anyo
hugis target [MACRONAME=value ...].

Sa detalye, awtomatikong ginagawa ng shape_RMS ang mga sumusunod na aksyon, na ang bawat isa ay
inilarawan sa isinangguni na pahina ng manwal.

·
Pagbuo, pag-install, at paglilinis ng system (hugis_buo(1)).

·
Pagbuo ng mga prerelease ng mga subsystem o ang buong sistema (shape_releas(1)).

·
Pagbuo ng mga paglabas ng mga subsystem o ang buong sistema (shape_releas(1)).

·
Paggawa ng mga patch sa mga kasalukuyang release (hugis_patch(1)).

·
Reinstantiation ng lumang system release (shape_releas(1))

·
Paglikha ng mga shippable na pakete (tar o shar file, atbp.) (hugis_tar(1)).

·
Pagpapasiya ng mga dependency ng file (hugis_depende(1)).

Bukod pa rito, nagbibigay ito

·
Mga panuntunan sa pagpili ng karaniwang bersyon (hugis_stdrul(7)).

·
Isang malawak na proyektong pinag-isang variant control raster (shape_stdvar(7)).

·
Awtomatikong pagbuo ng (pre)release na mga pagkakakilanlan.

·
Pag-iimbak ng partikular na impormasyon sa pamamahala ng configuration sa bawat bahagi ng system.

·
Mga Template para sa Shapefiles at Makefiles (shape_tmpl(7)).

Ang proyekto kaayusan

Ang pangkalahatang istraktura ng proyekto ay hierarchical. Bawat isa buko sa hierarchy ay binubuo ng a
bilang ng mga components at isang bilang ng subsystem. Ang tuktok na node sa hierarchy ay kumakatawan
ang buong sistema. Ang tatlong terminong ito - node (o system node), component at subsystem -
ay gagamitin sa lahat ng shape_RMS manual page. Ang isang subsystem at isang system node ay ang
parehong bagay sa prinsipyo, na binubuo ng mga bahagi at subsystem. Ang mga paniwala sa halip
makilala ang dalawang magkaibang pananaw.

Ang hierarchical na istraktura ay makikita sa isang puno ng direktoryo ng UNIX na may mga direktoryo
kumakatawan sa mga node at file bilang mga bahagi ng system. Hindi kinakailangang may hawak na a
buong system node. Ang mga solong node ay maaaring kumalat sa maraming direktoryo na bumubuo ng isang subtree.
Ang nangungunang direktoryo ng subtree na ito ay ang kinatawan ng node. Samakatuwid, ang sistema
ang istraktura at ang puno ng direktoryo ay maaaring magkaiba.

Ang istraktura ng proyekto at ang mga bahagi nito ay inilalarawan ng sistema modelo. Ang sistema
Ang modelo ay binubuo ng isang pinagsama-samang koleksyon ng mga Shapefiles at Makefiles. Ang bawat node ay
nilagyan ng isang Makefile at isang Shapefile na naglalaman ng node specific system model
impormasyon. Karagdagang impormasyon ng modelo ng system (tulad ng mga panuntunan sa pagpili ng karaniwang bersyon
o project wide variant definitions) ay pinananatili sa isang project wide central place at
na-access sa pamamagitan ng shape's include facility.

Ang functional na profile ng modelo ng system ay makikita sa pamamagitan ng paunang natukoy pamantayan target in
ang mga file ng modelo ng system (Shape- at Makefiles). Ang mga target na ito ay tinukoy alinman sa
indibidwal (node ​​specific) Shape- at Makefiles o sa isa sa mga kasamang Shapefile
pinapanatili ng mga fragment ang project wide Shapefile. Isang set ng pamantayan macros at implicitly isang set
ng mga kumbensiyon na sumasailalim sa mga macro na iyon ay binubuo ng data interface sa pagitan ng iba't-ibang
mga module ng modelo ng system. Pagsunod sa mga kinakailangang pinagbabatayan na mga kombensiyon at
ang mga pagpapalagay ay pinadali ng mga template para sa Shape- at Makefiles na ibinibigay sa
programmer ng iba't ibang bahagi ng system (tingnan shape_tmpl(7)). Ang paggamit ng mga template na ito ay gumagawa
ang impormasyon ng modelo ng sistema ng pagsulat ay halos walang halaga.

Ayon sa mga template, ang mga bahagi ng Makefile ay naglalaman ng karamihan sa mga kahulugan ng macro, ang
karaniwang mga kahulugan ng dependency ng bahagi at karamihan sa mga tahasang panuntunan sa pagbabago. Ang
Ang sistema ng Makefiles ay maingat na idinisenyo upang maging sapat na selfcontained upang magamit nang wala
hugis(1). Ito ay kinakailangan upang magbigay ng isang pamamaraan ng pagbuo para sa pag-compile at pag-install
software system sa labas ng development area (kung saan hugis(1) kadalasan ay hindi magagamit).

Ang mga bahagi ng Shapefile ay naglalaman ng impormasyon na partikular na nauugnay sa mga hugis
mga espesyal na feature na hindi available sa make (hal. pagpili ng bersyon, paghawak ng variant).
Ang kumpletong sistema ng Shape- and Makefiles ay walang redundancy, na nagpapadali sa mga ito
mapanatili. Ang Shapefiles, upang kumatawan sa isang kumpletong modelo ng system, ay naglalaman ng kasama
mga direktiba na isama ang lahat ng makabuluhang impormasyon ng modelo ng system na nakaimbak sa iba pa
mga bagay, lalo na ang centrally maintained kasama ang mga file at ang Makefiles.

Ang gawaing pagpapaunlad ay karaniwang nangyayari sa mga developer' pribado lugar ng trabaho, Sa pamamagitan ng
mga resultang nakalap sa isang sentral na lokasyon, ang mga proyekto pinagmulan repositoryo. Ang pinagmulan
Ang repository ay isang kumpletong puno ng direktoryo (kumpleto sa kahulugan ng pagsasama ng bawat isa
binuo system node) na kumakatawan sa buong proyekto. Mga pribadong workspace at
Ang mga kaukulang subdirectory sa source repository ay pinagsama-sama ng common AtFS
mga subdirectory (tingnan vcintro(1)) hawak ang lahat ng naka-save na resulta ng trabaho (mga bersyon). Itong mekaniko
ginagawang nakikita ang mga file mula sa isang pribadong workspace sa source repository, sa sandaling ang
nagse-save ang developer ng kopya ng isang file gamit ang shapeTools version control system. Pag-unlad
maaari ding mangyari ang trabaho sa source repository. Sa kasong ito, kahit na ang abalang bersyon ng bawat isa
Ang workpiece ay makikita sa source repository, na hindi nakakaabala.

Ang bawat node sa system ay dapat maglaman ng release identification file. Ang file na ito ay
awtomatikong pinananatili at hindi dapat baguhin nang manu-mano. Dapat din itong hango
mula sa isang ibinigay na template at naglalaman ng isang string na binabanggit ang pangalan ng node at ang aktwal na paglabas
numero. Sa bawat bagong release, isang bagong bersyon ng release identification file ay
nabuo. Sa pagbuo ng software, kadalasang naglalaman ito ng nakagawiang pagbabalik ng release
string ng pagkakakilanlan na binanggit sa itaas. Ang mekanismong ito ay nag-o-automate ng release identification sa
mga sistema ng software.

Sa tabi ng mga pribadong workspace at source repository, ang isang proyekto ay may a may pinapanigan pakawalan lugar at
a pakawalan lugar. Ang parehong mga lugar ay may kakayahang humawak ng kumpletong kopya ng pinagmulan ng proyekto
tree bilang mga file ng UNIX (walang kontrol sa bersyon). Ang may pinapanigan pakawalan lugar may pinakamaraming hawak
kamakailang (pre-)release ng bawat node ng system. Sa bawat oras, ang isang node ng system ay paunang inilabas o
inilabas, ang isang kopya ng mga kasangkot na bersyon ng pinagmulan ay nakasulat sa bahagyang lugar ng paglabas.
Ang pakawalan lugar nagtataglay ng mga prerelease at release ng buong system. Ito ay napuno lamang,
kapag ang isang (pre-) release na pamamaraan ng pagbuo ay na-trigger mula sa tuktok na node ng pinagmulan
imbakan. Makakakita ka ng higit pang mga detalye sa paksang ito sa shape_releas(1) manu-manong pahina.

Ang Pag-unlad paraan

Ang pangkalahatang proseso ng pag-unlad na ipinataw ng shape release management system ay
inilalarawan ng sumusunod na pattern.

1)
lokal na pag-unlad at pagsubok sa mga pribadong workspace na may mga lokal na bersyon (i-save ang)

2)
indibidwal na prepublication ng single node system (buko prerelease)

3)
pandaigdigang integration at integration testing (tuktok prerelease)

4)
pagsasama ng mga kahilingan sa pagbabago mula sa pandaigdigang pagsasama sa mga single node system at
panghuling publikasyon ng mga sistema ng node (buko pakawalan)

5)
global release (tuktok pakawalan)

6)
lokal na pagpapakilala ng mga pag-aayos ng bug sa inilabas na sistema (buko magtagpi prerelease).

7)
pandaigdigang integrasyon ng mga patch at integration testing (tuktok magtagpi prerelease).

8)
mga lokal na release ng patched node system releases (buko magtagpi pakawalan).

9)
pagbuo ng global patched release (tuktok magtagpi pakawalan).

Siyempre, maaaring mayroong ilang mga loop sa listahan sa itaas. Una, ang pagtatayo ng buko
(pre-)release nangyayari nang paulit-ulit mula sa mga dahon ng system source tree hanggang sa itaas.
Pangalawa, ilang mga pag-ulit ng node/itaas prerelease karaniwang kinakailangan ang mekanismo,
upang makarating sa isang matatag na huling paglabas.

Ang indibidwal na pag-develop at pagsubok ay nangyayari sa mga pribadong workspace ng mga indibidwal na developer. A
karaniwang gumagamit ang developer ng mga lokal na abalang bersyon at ang pinakabagong inilabas na mga bahagi ng lahat
iba pang mga bahagi ng system na kailangan niya (hal. mga aklatan) upang masubukan ang kanyang bahagi. Nasa pagitan
ang mga resulta ng indibidwal na gawain sa pagpapaunlad ay maaaring i-save sa base ng bersyon. Ang
kaukulang katayuan ng mga umuusbong na bersyon ay ligtas.

Kapag ang developer ay nag-iisip na ang isang matatag na estado ng pag-unlad ay naabot o isang pag-unlad
transaksyon ay nakumpleto na siya ay nagsasagawa ng isang indibidwal na prerelease ng kanyang mga resulta ng trabaho.
Ang nasabing paglabas ng mga resulta ng trabaho ay binubuo ng pag-save ng lahat ng hindi pa nase-save na abalang bersyon sa
base ng bersyon, na nagmamarka sa lahat ng bahagi ng pinaghirapang subsystem (ibig sabihin, lahat ng pinakabago
bersyon) na may karaniwan, natatangi, at mahusay na tinukoy na lokal na releasename, at itinalaga ang
katayuan iminungkahi sa lahat ng bersyong ito. Ang mga bersyong ito, bilang naninirahan sa gitnang pinagmulan
Ang repositoryo ay naa-access sa buong mundo para sa system integrator.

Ang global integration at integration testing ay ginagawa ng isang espesyal na user, ang integrator.
Ang integrator ay karaniwang hindi gumagawa ng anumang aktwal na gawain sa pagpapaunlad sa kanyang sarili. Sa katunayan ang
Ang integrator ay isang konseptwal na gumagamit (ibig sabihin, isang espesyal na userId) na kumikilos sa gitnang pinagmulan
repository at samakatuwid ay may access sa lahat ng indibidwal na inilabas na mga bahagi at subsystem ng
ang binuong sistema. Kinokolekta ng integration testing ang lahat ng pinakakamakailang indibidwal na prerelease
(ng mga bahagi at subsystem) at lumilikha ng prerelease ng binuong sistema. Lahat
ang mga bahagi na bahagi ng isang prerelease ay minarkahan ng isang karaniwan, natatangi, at mahusay na
tinukoy ang pandaigdigang prereleasename, at itinalaga ang status ng bersyon nai-publish.

Ang layunin ng paunang pagpapalabas ng system bago ang aktwal na pagpapalabas nito, ay upang tiyakin iyon
lahat ng mga bahagi ay gumagana nang maayos, ang pamamaraan ng pag-install ng system ay gumagana nang maayos,
ang bagong release ay bumubuo, nag-i-install, at tumatakbo nang tama sa lahat ng sinusuportahang platform nang wala
ang panganib ng pagtatalaga (at sa gayon ay pag-aaksaya) ng nakaplanong opisyal na releasename nang wala sa panahon.
Sa panahon ng integration testing, walang mga bagong feature o pagpapahusay ang dapat pahintulutan
isinama sa sistema. Ang tanging uri ng kahilingan sa pagbabago na dapat
naproseso sa yugtong ito ay mga bug sa pamamaraan ng pag-install at kakayahang dalhin
mga problema (kabilang dito ang pag-aayos ng mga bug na makikita habang nag-port).

Kapag ang prerelease cycle ay nakagawa ng isang matatag na estado ng buong system, maaari na
opisyal na inilabas. Ang opisyal na pamamaraan ng pagpapalabas ay katulad ng prerelease
pamamaraan, ngunit minarkahan ang lahat ng mga bahagi ng nakaplanong opisyal na pangalan ng pagpapalabas, at itinalaga ang
katayuan ng bersyon frozen sa kanila.

Pagtatakda ng up a proyekto

Sa sumusunod na makikita mo ang dalawang checklist. Ang una ay nagsasabi, kung ano ang gagawin kapag nagpasimula ng a
proyekto bilang tagapangasiwa ng proyekto. Ang pangalawa ay tumutulong , kumokonekta sa isang itinatag
proyekto bilang developer.

Checklist para sa paunang setup:

A1)
Lumikha ng isang (UNIX) na gumagamit upang maging proyekto may-ari. Ito ay dapat na isang konseptong gumagamit, hindi isang
natural. Ang home directory ng user na ito ay ang proyekto bahay.

A2)
Tukuyin ang a proyekto grupo (Sa / atbp / pangkat) at idagdag ang lahat ng kalahok sa proyekto sa pangkat na ito.

A3)
I-set up ang sentral na proyekto pinagmulan repositoryo sa bahay ng may-ari ng proyekto.

· Lumikha pag-unlad direktoryo

· Lumikha libo, lib at isama direktoryo sa direktoryo ng pag-unlad.

· I-install ang system source tree gamit ang SRC direktoryo sa direktoryo ng pag-unlad bilang
root.

· Lumikha ng isang direktoryo na pinangalanan AtFS sa bawat direktoryo ng puno ng pinagmulan ng system.

A4)
I-set up ang release at partial release na mga lugar sa pamamagitan ng paggawa ng mga direktoryo pakawalan at
bahagyang.paglabas sa bahay ng may-ari ng proyekto.

A5)
gumawa lahat dati nang nilikhang mga direktoryo na maaaring isulat ng pangkat.

A6)
Lumikha ng isang direktoryo na pinangalanan hugis sa development/lib at kopyahin ang shape_RMS na mga template at
isama ang mga file sa direktoryong iyon.
Ito ay ang Shapefile.tmpl, Makefile.tmpl, Release.tmpl, release.c.tmpl, stdconf,
stdtargets, stdrules at stdvar.

A7)
Ayusin ang mga macro default na halaga sa Makefile.tmpl at Shapefile.tmpl in
pag-unlad/lib/hugis ayon sa lokal na pag-install. Ang shape_tmpl(7) manwal na pahina
nagbibigay sa iyo ng impormasyon tungkol sa mga semantika ng bawat macro definition. Ang Makefile
tinutukoy ng template

· base path para sa source repository, partial release area, release area, at
mga lokasyon ng pag-install ng system.

· isang paglalarawan ng kapaligiran ng host system.

· mga tool at tool na pagpipilian na gagamitin.

· mga aklatan na gagamitin.

· default na mga aksyon sa pagbuo at pag-install.

A8)
Suriin ang stdvar (project wide variant definitions) file. Tingnan mo shape_stdvar(7) para sa
karagdagang impormasyon tungkol dito.

Kung mahigpit kang mananatili sa structuring at release model gaya ng ipinatupad sa mga template
at kasama sa hugis ang mga file na ibinigay sa pamamahagi ng shapeTools, tapos na ang iyong trabaho ngayon.
Ang mga karagdagang adaptasyon ay nangangailangan ng mga pagbabago na manu-manong maisagawa sa mga file sa hugis/lib.
Bago mo gawin ito, inirerekomenda naming basahin muna ang tutorial ng shapeTools. Lalo na ang
Makefile template dapat mong i-set up nang maingat. Tulad ng karamihan gumawa(1) ginagawa ng mga pagpapatupad
hindi sumusuporta sa pagsasama ng mga panlabas na bahagi sa Makefiles, lokal na Makefiles (nagmula sa
template) nagtataglay ng maraming impormasyon na dapat na mas mahusay na mapanatili sa gitna.
Mga pagbabago sa template ng Makefile na ginawa pagkatapos na magkaroon ng mga lokal na Makefile
mula dito, nangangailangan ng pag-patch ng mga pagbabago sa bawat lokal na Makefile. Ito ay isang magastos at
trabahong madaling pagkakamali. Inirerekomenda naming gamitin magtagpi(1) para dito, na talagang hindi ikaw
nais, ngunit wala pang mas mahusay na solusyon.

A9)
tukuyin ang mga panuntunan sa pagpili ng bersyon

A10)
magpatupad ng mga karagdagang aksyon sa mga stdtarget or stdconf.

A11)
muling tukuyin ang mga patakaran sa malawak na proyekto sa Makefile.tmpl, Shapefile.tmpl, O stdconf.

Huwag subukang humanap ng anumang karagdagang dokumentasyong gumagabay sa mga puntong A9-A11. meron
wala pa.

Checklist para sa mga developer, kapag kumokonekta sa isang kasalukuyang proyekto:

D1)
Siguraduhing maging miyembro ng pangkat ng proyekto

D2)
Lumikha ng pribadong direktoryo ng pag-unlad

D3)
Kumonekta sa gitna pinagmulan repositoryo sa pamamagitan ng pagtatatag ng isang link na pinangalanan AtFS mula sa iyong
lokal na direktoryo ng pagpapaunlad sa kaukulang direktoryo sa gitnang pinagmulan
imbakan. Ito ay dapat na isang simbolikong link sa direktoryo ng AtFS doon, o, sa
mga system kung saan walang available na symbolic link facility, isang file na may naaangkop
pathname bilang mga nilalaman. Ang huli ay bibigyang-kahulugan ng control ng bersyon ng shapeTools
system bilang kahalili para sa isang simbolikong link.

D4)
Kopyahin Makefile.tmpl mula sa project_home/lib/shape as Makefile sa iyong pag-unlad
direktoryo at punan ang mga kinakailangang kahulugan ng macro sa pamamagitan ng pag-edit ng file. kung ikaw
mayroon nang Makefile, huwag mo nang subukang gamitin pa iyon. Mas magiging maswerte ka
na may Makefile na nagmula sa template.

D5)
Kopyahin Shapefile.tmpl as Shapefile sa iyong development directory. Kadalasan, hindi
kailangan ang mga pagbabago doon.

D6)
Kopyahin ang isa sa Release.tmpl or release.c.tmpl bilang Paglabas, resp. release.c sa iyong lokal
direktoryo.

D7)
Lumikha ng walang laman Dependencies file at tumakbo hugis manangan (1) pagkatapos. Suriin, kung ang iyong
Sinusuportahan ng setup ng proyekto ang awtomatikong pagbuo ng Dependencies file. Kung hindi, mayroon ka
upang mapanatili ito nang manu-mano.

D8)
Tumakbo hugis rms (1) upang makakuha ng buod ng mga function na ibinigay ng shapeTools
release na sistema ng pamamahala.

MGA KATANGIAN

Bilang toolkit ng hugis ay may isang Na-attribute Filesystem (AtFS, Tingnan ang afintro(3)) bilang imbakan ng data
base, iniimbak ng shape_RMS ang panloob na impormasyon sa pamamahala bilang mga katangian na naka-attach sa
mga bahagi ng system. Ang mga katangian ay binubuo ng pangalan at isang listahan ng mga halaga. Configuration
mga katangiang nauugnay sa pamamahala ay

__SymbolicName__
Ang bawat bahaging bersyon sa system ay nagdadala ng isang set ng mga simbolikong pangalan na kakaiba
pagtukoy sa (mga) bago ang pagpapalabas, ito ay bahagi ng. Maaaring walang laman ang listahang ito, kapag a
ang bersyon ay hindi kailanman idineklara na bahagi ng isang (pre-)release. __SymbolicName__ ay isang
attribute na may espesyal na kahulugan sa lahat ng mga programa sa shapeTools. Para sa karagdagang
impormasyon tingnan ang -simboliko opsyon ng vl(1) at vadm(1).

nodename
Ay ang pangalan ng sistema ng node, ang bersyon ng bahagi ay kabilang sa bilang tinukoy sa
NODENAME macro sa Makefile ng subsystem. Tanging ang release number generator file
nagdadala ng katangiang ito.

lastrelease
Ang natatanging pangalan ng huling nabuong prerelease o release. Nakukuha ang katangiang ito
naka-attach lamang sa mga bersyon ng release number generator file. Sa katunayan, ito ay gumagawa
pakiramdam lamang sa pinakabagong bersyon ng release number generator file.

Gumamit ng shape_RMS online gamit ang mga serbisyo ng onworks.net