QGIS ja versionumerot: mitä numerot kertovat?
Avoimen lähdekoodin QGIS-paikkatieto-ohjelmisto kehittyy hurjaa vauhtia ja kerää taakseen vinon pinon versionumeroita. Tarkoituksenani on nyt avata hieman logiikkaa eri QGIS-versioiden takana: mitä ohjelmiston versionumerot pyrkivät kertomaan käyttäjälleen? Kaikki tieto, minkä jaan tässä artikkelissa, pohjautuu täältä löytyvään QGISin tiekarttaan.
Ohjelmiston versionumerointi ja QGISin kehityksen vaiheet
Tutustutaan ensimmäiseksi ohjelmiston versionumeroinnin taustoihin sekä QGIS-ohjelmiston kehitysprosesseihin. Ohjelmiston versionumero (esimerkiksi 3.12.1) rakentuu yleensä 2-3 eri luvusta, jotka kertovat ohjelmiston kehitysvaiheesta. Lukujen sisään kätkeytyy erilaisia prosesseja ja logiikoita, joiden kautta siirrytään versionumerosta toiseen.
Major-, Minor- ja Patch-julkaisut
Versionumeron ensimmäinen luku viittaa Major-versioon, johon ohjelmiston päärakenne pohjautuu. Jos ohjelmisto siirtyy Major-versiosta toiseen, ohjelmistoon tehty kehitys on laaja-alaista eikä ohjelmisto ole enää yhteensopiva aikaisemman Major-version ominaisuuksien kanssa (esimerkiksi lisäosat). Esimerkiksi QGISin kehittyessä 2.18-versiosta 3.0-versioon, monet QGIS 2.18-versiolle tehdyt lisäosat eivät enää toimineet QGIS 3.0-versiossa. Myös QGISin graafinen ilme muuttui merkittävästi uudessa Major-versiossa.
Major-luvusta seuraava on Minor-versiota ilmaiseva luku. Minor-julkaisussa ohjelmisto on edelleen joko yksi tai useampi uusi ominaisuus, mutta ohjelmisto pysyy edelleen yhteensopivana aikaisempien Minor-versioiden kanssa. Yleensä ennen uutta Major-julkaisua seuraa liuta pienempiä Minor-julkaisuja (esimerkiksi 3.1, 3.2, 3.3, 3.4…).
Minor-julkaisuakin pienempiskaalaisempi on Patch-julkaisu. Tässä versiossa kehittäjät ovat yleensä korjanneet raportoituja bugeja tai lisänneet ohjelmistoon yhden uuden ominaisuuden. QGISin kohdalla Patch-julkaisuja nimitetään myös vaihejulkaisuiksi eli Point releaseiksi (PR). Eri ohjelmistojen versionumerointi voi edetä Patch-julkaisuakin pidemmälle, mutta pääperiaate on yleensä sama: mitä kauempana numero on Major-luvusta, sitä pienempialaisempaa tehty ohjelmistokehitys on.
QGISin kehitys ja ohjelmistokehitys noin yleisestikin (poislukien pienet nyanssit) noudattavat tiettyjä prosesseja versionumerosta toiseen siirryttäessä. Kehitysprosessi voidaan karkeasti jaotella kolmeen eri vaiheeseen: varsinaiseen kehitysvaiheeseen (development phase), jäädytysvaiheeseen (freeze phase) sekä julkaisuvaiheeseen (release phase). Sekä QGISin viimeisin versio että pitkäaikaisversio (LTR) noudattavat näitä kehitysvaiheita omissa kehityslinjoissaan.
Kehitysvaihe (development phase)
Kehitysvaiheessa QGISiin lisätään uusia toiminnallisuuksia tai olemassaolevia toimintoja kehitetään eteenpäin. Kehitysvaihe jakautuu yleensä useampiin pienempiin vaiheisiin, joissa keskitytään vain tietyn toiminnallisuuden kehitykseen. Jokaisesta pienemmästä kehitysvaiheesta ja uuden toiminnallisuuden lisäämisestä julkaistaan aina oma vaihejulkaisu (PR) tai Patch-versio. Esimerkiksi QGIS-versiot 3.12.1 ja 3.12.2 ovat Patch-julkaisuja/vaihejulkaisuja, joissa ohjelmistoon on lisätty jokin pienempi toiminnallisuus (tai vaihtoehtoisesti korjattu bugeja tai tehty molempia). Kehitysvaiheessa luodaan liuta erilaisia Patch-julkaisuja.
Jäädytysvaihe (freeze phase)
Jäädytysvaiheessa QGISiin ei lisätä enää uusia toiminnallisuuksia, vaan aikaisemmassa kehitysvaiheessa lisättyjä ominaisuuksia pyritään stabiloimaan. Stabiloinnilla tarkoitetaan sitä, että uudet ominaisuudet pyritään saada niin luotettaviksi kuin mahdollista. Käytännössä siis eliminoidaan käytössä havaittuja bugeja, ongelmia ja muita uuden ominaisuuden suoritusta heikentäviä tekijöitä. Jäädytysvaiheessa QGISistä ei yleensä julkaista kuin 1-2 Patch-versiota.
Jotta QGIS pysyisi mahdollisimman stabiilina ja luotettavana, tulisi käyttäjien aina laatia bugiraportti kohtaamistaan ongelmista. Ilman raportointia kehittäjät eivät välttämättä edes tiedä ongelman olemassaolosta, eikä bugi näin ollen katoa! Kerron lisää QGISin bugiraportoinnista artikkelin lopussa.
Julkaisuvaihe (release phase)
Julkaisuvaihe on QGIS-ohjelmistokehityksen viimeinen vaihe. Tässä vaiheessa QGISiin on lisätty uusia ominaisuuksia ja nämä ominaisuudet on stabiloitu niin hyvin kuin mahdollista. QGIS ja sen uudet stabiloidut toiminnallisuudet siirtyvät paketointiin ja lopuksi se julkaistaan myös loppukäyttäjän saataville. Tässä kehityksen loppuvaiheessa QGISistä julkaistaan Minor-versio, joka sisältää kaikki kehitysvaiheessa lisätyt ja jäädytysvaiheessa stabiloidut uudet ominaisuudet. Kun julkaisu on tehty, koko prosessi alkaa alusta ensimmäisestä vaiheesta ja versionumerointi etenee 0 Patch-versiosta eteenpäin. Esimerkiksi QGIS-versio 3.10.0 on kehitysprosessin lopputuote, josta alkaa jälleen uusi kehityssykli.
QGISin kehitys perustuu aikajänteisiin
Jokaiselle edellä mainitulle vaiheelle on määritelty tietty aikajänne, minkä aikana vaihe tulee aloittaa ja saatta loppuun. Tällä vältetään “lipsumista”, kun jokaisesta vaiheesta on olemassa deadline. QGISin kehitys on suunniteltu niin, että joka neljäs kuukausi julkaistaan uusi QGISin Minor-versio. Kehitysvaiheeseen pyritään varaamaan kolme kuukautta (3 x 4 viikkoa) ja jäädytysvaiheeseen yksi kuukausi (1 x 4 viikkoa). Julkaisuvaihe pyritään tekemään samanaikaisesti seuraavan kehitysvaiheen alun kanssa.
Bugiraportin laatiminen
Kun QGIS siirtyy jäädytysvaiheeseen, on aika laittaa kokeiluhattu päähän ja lähteä oikein urakalla testaamaan QGISin uusimpia ominaisuuksia! Mistä sitten uusimman ominaisuudet oikein löytää? Eri QGIS-versioiden muutoksista pidetään kirjaa muutoslokissa (changelog). Tätä kautta voi napsia testiin juuri sinua kiinnostavia uusia ominaisuuksia.
Kuten aiemmin mainitsin, QGISin jäädytysvaiheessa kehittäjät pyrkivät stabiloimaan uusimman version ja sen uudet ominaisuudet. Bugien kokonaisvaltainen korjaus on kuitenkin haastavaa ilman käyttäjäyhteisön tukea, minkä vuoksi bugiraporttien laatiminen on äärimmäisen tärkeää. QGISin kohdalla raportointi on pyritty tekemään mahdollisimman helpoksi, sillä raportti laaditaan valmiille bugiraporttipohjalle QGISin GitHubissa. Raporttipohja sisältää kaiken tiedon siitä, mitä sinun tulee kertoa kehittäjälle, jotta bugi saadaan nitistettyä.
Jos bugiraportin kirjoittaminen englanniksi tai GitHubin käyttö ei jostain syystä luonnistu, QGISin bugilöydöistä voit kertoa myös esimerkiksi Gispon tukipalvelussa! Tukipalvelussa haluamme tietää etenkin käyttämäsi QGIS-version, käyttämäsi aineiston sekä mahdollisimman tarkan ohjeistuksen miten saisimme replikoitua bugin vielä itse (= eli kerro mitä teit, että sait bugin näkyviin QGISissä).
Bugiraportteja saa ja pitääkin kirjoittaa aina, kun löydät ohjelmistosta jotain hämärää – jäädytysvaihe on tavallaan vain tehovaihe, jossa kehittäjät keskittyvät uusien ominaisuuksien bugikorjauksiin ja stabilointiin. Avoimen lähdekoodin QGIS-ohjelmiston kunnossapito ei ole vain kehittäjien työtä, vaan vastuu kuuluu myös käyttäjille!
Lähteet:
https://www.qgis.org/en/site/getinvolved/development/roadmap.html#
https://www.qgis.org/en/site/forusers/visualchangelogs.html
