Sokszor, hoztad elő és sokszor magyaráztam el neked, hogy ennek mi volt az oka.
Nekifutok még egyszer...
Amikor egy forráskódot kiad egy FOSS projekt akkor elsősorban a kód megmutatása a cél. Tessék, itt van a kód, lehet nézegetni. Ez arról szól, hogy akit érdekel az megnézheti, hogy a licenszek rendben vannak-e, tartalmaz-e lopott kódot vagy egyértelmű spywaretm, mallwaret. Ilyenkor messze nem az a cél, hogy a kód minden környezetben forduljon csont nélkül és működjön.
Az, hogy neked nem fordul a kód az csak azt jelenti, hogy a kód nem portolható. Csomószor van olyan, hogy egy kód az én fejlesztői környezetemben még fordul, de máshol nem. A kód portolhatósága már csomagolási feladat, ahol biztosítjuk, hogy a forduláskor jelen legyenek a megfelelő API csomagok, könyvtárak és a megfelelő toolchain és fordítási eszközök.
Tehát van az a fázisa publikálásnak amikor a kódot mutatjuk meg "csak a szemnek".
A második fázisa az amikor a kód portolható, vagyis elvárható, hogy forduljon. Ez tényleg csak annyit jelent, hogy lehúzod a targézát és az cmake/qmake és make parancsra (vagy ezzel ekvivalensre) fordul és legyártja a binárisokat. Ez még mindig nem jelenti azt, hogy futtatható, integrálható lesz a FOSS projekt végterméke.
A harmadik fázis az amikor a kód fordul, csomagolható és akár futtatható is. Ez az amit te félreértettél. Ugyanis ez még messze nem arról szól, hogy csinál bármit a program. Egyszerűen csak lefuttatható és nem dob core-t, nem eszi meg a CPU-t nem foggyasztja el a memóriát és nem blokkol semmilyen rendszer erőforrást, valamint nem csinál semmi gonoszságot.
Ez a fázis a test driven development egyik alapja. Minden test driven development úgy kezdődik, hogy megírunk egy fordítható, futtatható main{} függvényt és csinálunk gy tesztet, hogy a program elindul és kilép.
Ez után a fázis után ágazik el a fejlesztés annyi irányban ahány felhasználói use-case/feature/epic vagy ami éppen használatos a projekben. Az egyes fícsörök lépésenként kerülnek be rendszerbe és minden újabb kiadás tartalmaz valami újat.
A fejlesztés ebben a fázisban _NEM_ lineáris, a kiadások viszont azok. Vagyis valamilyen prioritási sorrendben kerülnek bele a fícsörök, bugfixek a lineáris kiadásokba. Ez a másik dolog amit te félreértettél... bár többször elmagyaráztam már. Vélhetőleg rosszul, ezért elnézésedet kérem.
Szóval, ha eg rendszernek két feladta van az egyik a kávéfőzés, a másik pedig a fagylalt gyártás, akkor ennek a két fícsörnek a megvalósítása egy adott prioritás sorrend alapján történik. Ha a kávéfőzési képesség fontosabb az ügyfélnek akkor azzal kezdjük. A FOSS modell lényege az, hogy akkor is kiadjuk, megmutatjuk a terméket ha az még nincs kész (release early, release often) Ilyenkor sorozatban vannak olyan kiadások ahol a kávéfőzéssel kapcsoltos fícsörök javulnak, bővülnek és az ezzel kapcsolatos bugok fixálódnak... ilyenkor persze csodálkozhat a fogyasztó, hogy hát itt van a fagyigép rész ami nem működik. Ez az amit te is csinálsz...
Pedig egyszerűen arról van szó, hogy a fagyi készítés a fontossági sorrendben a kávéfőzés után következik.
Szóval, viszatérve az esetre amit te felvetsz...
A Unity8 konvergenciájának az egyik alapja, hogy az elérhető adtbeviteli mód és perifériák alapján adaptálódik a környezet és az alkalmazások. Vagyis ha van egér és tasztatúra akkor asztali körenyezetet feltételezünk és úgy nézünk ki, ha pedig csak érintőképernyő van akkor mérettől függetlenül vagy phone vagy tablet módoba megyünk.
A Unity8-nek egyértelműen a phone mód a prioritás. Ugyanis telefonra nincsen használható Unity7. Vagyis ameddig a desktop júzereknek van egy működő WM és grafikus shell, addig a telefonos júzereknek csak a unity8 van.
Ezért a fejlesztési prioritásokat a telefonos mód szabta meg.
Az Unity8-nak és minden arra épülő keretrendszernek és core alkalmazásnak az OTA 8-9-10 kiadások célozzák meg azt a konvergenica use case-eket amikben az ilyen úgynevezett "capability" alapú adaptáció történik.
Vagyis egész egyszerűen azon a fícsörön amit te hiányolsz nem dolgozott senki. Egy adott és meghatározott prioritási sorrendben haladt a Unity8 csapat és a FOSS modellt követve a köztes kiadásokat is ki lehetett próbálni.
Való igaz, hogy meddig nem feküdt rá a csapat arra, hogy a Unity8 egy asztali környezetben is úgy működjön ahogy azt a felhsználók és a funkcionális tesztek megkövetelik addig a desktop környezetre a Unity8 kiadás csak mint kód, fordítható kód és futtatható kód léetezett... mint használható és működő kód _NEM_
Remélem, hogy így már egyértelműbb, hogy miről van szó. Ha még így sem jön le a dolog akkor vagy én magyarázok nagyon rosszul és akkor inkább hagyjuk. De ha kérdésed van akkor szólj.