Updater plugin Alpha

Podpora vývojářů nových pluginů, oznámení o nových pluginech nezávislých autorů a diskuse o nich.
User avatar
zarevak
Plugin Developer
Plugin Developer
Posts: 789
Joined: 04 Feb 2006, 16:49
Location: Prague, Czech Republic

Post by zarevak »

Ten counter mne taky napadl (používal jsem ho v jednom komerčním systému), jenže to bych musel vědět hodnotu toho counteru pro každý nainstalovaný plugin.

Jiná cesta je, aby plugin reportoval aktuální verze pluginů zpět serveru, ten by měl databázi známých verzí a buď by doporučil update nebo nahlásil, že kombinaci verze/plugin nezná. To by se však nemuselo líbit některým uživatelům pečujícím o své soukromí. (Teď plugins stahuje statický manifest přes HTTP a v UserAgent hlavičce reportuje pouze svoji verzi)

Vzhledem k přání vytvořit jednoduchý update systém podobný Firefoxu si myslím, že přesvědčit vývojáře používat standardizovaný formát verzí bude nejschůdnější cesta.
V popdsatě všechny pluginy tvořené podle aktuálního SDK a Demopluginu v něm obsaženém již standardizované jsou - major.minorA[minorB][ betatxt]:
- minorB je přidáno do řetězce jen pokud je jiné než 0 (proto 1.2=1.20<1.21<1.3=1.30, jak psal Jan Patera)
- betatxt odpovídá Salamanderu a je pro finální verze Salamandera prázdný; pro betu a RC Salamandera obsahuje popis těchto verzí (v současnosti: "beta 1").

Tento systém má však své nedostatky:
- chybí udání verze patche/revize/build number (jádro Salamandera 2.52 beta 1 již existuje v relase verzi, v opravené verzi a pak možná v privátních opravených verzích - vše se však tváří jako stejná verze "2.52 beta 1")
- nikde není stanoveno, že minorA a minorB musí být menší než 10
- betatxt je uživatelem (Altapem) definovaný řetězec, který nemá pevně stanoven budoucí formát.

Jiné aktuálně pluginy používané verzovací systémy (význam domyšlen):
- major.minor.rev - pluginy od stepand76, WinSCP
- major.minor.build.rev - Total Commander File System Proxy Plugin

Navrhuji používat 2-4 čísla oddělená tečkou s případným doplňujícím řetězcem neovlivňujícím rozhodování o verzi. Tato čísla by byla porovnávána numericky (tedy 2<3<21).
- major.minor[.num3[.num4]] [textinfo]

Co by bylo třeba změnit:
- pokud je minorB rovno nule, tak ji stejně zobrazit nebo celé minorB posunout za tečku
- přidat do verze Salamandera číslo revize/buildu - toto číslo může být jen pro potřeby About dialogu (aby uživatel věděl, kterou verzi používá) a aktualizačního procesu a nemusí být zobrazeno v obvyklích místech obsahujícíc verzi (titulek okna).

Pokud by se porovnávání verzí provádělo lexikálně (tedy 2<21<3), tak je možno ignorovat změnu minorB, ale je nutné, aby vývojáři pluginů generovali verze v plné délce, pokud chtějí využívat více cifer (02<03<21)

Jaký návrh způsobu verzování máte vy? Jak je to řešeno ve Firefoxu?
User avatar
SelfMan
Posts: 1142
Joined: 05 Apr 2006, 20:51
Contact:

Post by SelfMan »

Ja som mal prave na mysli to, ze ten counter by bol sucastou pluginu. Myslim, ze nie je problem rezervovat WORD (double byte) pre takyto counter. Porovnanie uz by bolo potom velmi jednoduche. Ono v podstate aj taky timestamp ako je odporucany pri DNS zaznamoch nie je zlou informaciou - YYYYMMDDss (rok+mesiac+den+seriove cislo daneho dna)

Nemyslim, ze by niekto kompiloval modul viac ako 99x za den :-) (myslene pre ucely releasu.
Petr Solin
ALTAP Staff
ALTAP Staff
Posts: 1112
Joined: 08 Dec 2005, 09:13
Location: Novy Bor, Czech Republic
Contact:

Post by Petr Solin »

Ohledne te opravy 2.52 beta 1 beze zmeny verze, to je chyba (nebo spis odflaknuti) na me strane, mel jsem zvysit build number, ktery je posledni ve ctverici cisel verze (viz FILEVERSION v resourcech). Pro puvodne vydanou verzi je to 2.5.2.18 a patch mel byt 2.5.2.21 (19 a 20 uz jsme pouzili pro patchovane verze pluginu pro verze 2.5 a 2.51).

Jak tak ctu spl_vers.h, tak to vypada, ze jsme chteli to cislo buildu (pritomne ve vsech modulech, jak .exe, tak .spl i .slg) zvysovat pri kazde zmene (release, beta i jen patch jednomu uzivateli). Ovsem tezko to lze pouzit pro externi tvurce pluginu, tam bude jiste jednodussi proste zmenit cislo verze (prvni trojici cisel).

Jinak ja chapu cisla verzi jako desetina cisla, tedy 1.3 > 1.21 a 1.03 < 1.21, to vysvetluje i to vypousteni "zbytecnych" nul na konci verze, napr. 1.2 = 1.20.
Petr Solin
ALTAP Staff
ALTAP Staff
Posts: 1112
Joined: 08 Dec 2005, 09:13
Location: Novy Bor, Czech Republic
Contact:

Post by Petr Solin »

Pro ucely porovnani verzi by pripadne sel vyuzit i udaj "Time Date Stamp" zobrazeny v PEVieweru, jestli to chapu dobre, je uz dnes v kazdem nakompilovanem modulu a porovnani dvou je uz snadne. Kod na extrakci toho cisla bude pocitam trivialni (verim, ze i rychlejsi nez load celeho modulu do pameti).
User avatar
stepand76
Plugin Developer
Plugin Developer
Posts: 455
Joined: 16 Apr 2007, 21:22
Location: Pardubice, Czech Republic

Post by stepand76 »

zarevak wrote:Jaký návrh způsobu verzování máte vy? Jak je to řešeno ve Firefoxu?
V našem SW, který vyvíjíme, používáme konvenci A.B.C.D [SUFFIX], kde

A=major (jednomístné)
B=minor (jednomístné)
C=release (jednomístné až dvoumístné)
D=revision (SVN revize, ze které bylo sestavení provedeno - lze se pak jednoduše v SVN vrátit k dané verzi a ladit ji)
SUFFIX=nepovinný text (beta, pre-release, educational, ...), používáme výjimečně

např. 4.0.17.6264

Při porovnávání verzí (kontrola nové verze na serveru) používáme také manifest (v našem příadě jde xml soubor), který se stáhne via http. Verze se rozparsuje a porovnává se pouze č. revize.

V about boxech se zobrazuje pouze A.B.C, revize (D) je uvedena někde stranou aby to nepůsobilo pro uživatele složitě.

Jsme s tím maximálně spokojeni, ale pro případ pluginů pro AS je to asi nepoužitelné (ne každý používá SVN/CVS a když už tak každý jiný a když už stejný tak jiný repozitář).

Osobně se nebráním žádnému sjednocení označení verzí pluginů. To co navrhuješ je asi správné. Je potřeba verzi rozparsovat podle teček a jednotlivé části porovnávat numericky od nejvyšší k nejnižší. V případě, že to sedí, porovnat i řetězec za verzí. Tohle musí fungovat spolehlivě. Nebo ne?
User avatar
zarevak
Plugin Developer
Plugin Developer
Posts: 789
Joined: 04 Feb 2006, 16:49
Location: Prague, Czech Republic

Post by zarevak »

Petr Solin wrote:Pro puvodne vydanou verzi je to 2.5.2.18 a patch mel byt 2.5.2.21 (19 a 20 uz jsme pouzili pro patchovane verze pluginu pro verze 2.5 a 2.51).
Updater 0.1 využívá jen informace o verzi, kterou obdrží z CSalamanderGeneral::EnumInstalledModules(...). Tato funknce bohužel číslo patche nevrací. Dalším omezením tohoto postupu je, že případný aktualizovaný plugin se před svým načtením do Salamandera stále schovává pod starým číslem verze. Pokud se jedná o málo využívaný plugin, pak neaktuálnost jeho verze může updater hlásit docela dlouho.
stepand76 wrote:V našem SW, který vyvíjíme používáme konvenci A.B.C.D [SUFFIX], kde D=revision...
...Verze se rozparsuje a porovnává se pouze č. revize.
Tohle mi přijde rozumné; mám však pocit, že Altap používá CVS, takže nemají dostupné žádné jednotné číslo revize. Revizi lze případně nahradit datem jak popisoval SelfMan nebo jednoduchým číslem buildu/patche. Aby se neopomenulo tato čísla aktualizovat, tak by systém jejich generování měl být automatický a součástí relase procesu. Pro SVN lze použít SubWCRev.exe nebo jeho COM obdobu. Datum i build number lze generovat pomocí jednoduchého nástroje; např.: [1] [2]
User avatar
stepand76
Plugin Developer
Plugin Developer
Posts: 455
Joined: 16 Apr 2007, 21:22
Location: Pardubice, Czech Republic

Post by stepand76 »

zarevak wrote:Pro SVN lze použít SubWCRev.exe
Ano SubWCRev používáme. Používám to i ve svých pluginech.
User avatar
stepand76
Plugin Developer
Plugin Developer
Posts: 455
Joined: 16 Apr 2007, 21:22
Location: Pardubice, Czech Republic

Post by stepand76 »

zarevak wrote:Tady nastávají problémy, které jsem již popisoval v jiných vláknech o updatech:
1) Licence - nemohu si dovolit distribuovat pluginy bez svolení autora
Měl jsem na mysli příkaz který znovu vyhledá nové verze pluginů. Čili provede to co se stane při prvním otevření okna updateru. Nešlo mi o jeho stažení resp. instalaci. To by bylo taky super, ale o to mi zde nešlo.

Pokud by v databázi byl odkaz na soubor pluginu a updater by soubor stáhl nebyl by potřeba žádný souhlas autora. Nebo se pletu?

V okně updateru (a tedy i v databázi) by se hodilo mít i nějaký krátký popis pluginu (asi počítat s možností více jazyků).
User avatar
zarevak
Plugin Developer
Plugin Developer
Posts: 789
Joined: 04 Feb 2006, 16:49
Location: Prague, Czech Republic

Post by zarevak »

stepand76 wrote:Ano SubWCRev používáme. Používám to i ve svých pluginech.
Tvůj JSON Viewer:
- FILEVERSION resource: 0.3.0.18 - tak zobrazuje verzi standardní Windowsí Properties dialog
- About dialog: 0.3.0, Revision 238 - k této hodnotě se Updater nedostane :(
stepand76 wrote:Měl jsem na mysli příkaz který znovu vyhledá nové verze pluginů. Čili provede to co se stane při prvním otevření okna updateru. Nešlo mi o jeho stažení resp. instalaci. To by bylo taky super, ale o to mi zde nešlo.
Verze 0.1 už je pokrok - původní neuměla aktualizovat seznam ani zavřením a otevřením okna 8)
K aktualizaci: Myslím, že aktualizovat seznam z internetu nemá až takový význam, protože nové verze a nové pluginy se nebudou objevovat moc často.
Větší smysl má aktualizace verzí nainstalovaných pluginů - tady by se hodilo, aby Updater byl schopný plugin odnačíst (Unload) a znovu načíst. Bez jeho načtení totiž Salamander neaktualizuje čísla verzí a obnovení seznamu nepomůže.
Pokud Salamander neumožní pluginům zjistit nějakou přesnější verzi, tak budu muset implementovat čtení FILEVERSION resource - tu už si pak budu moci aktualizovat podle potřeby.
stepand76 wrote:Pokud by v databázi byl odkaz na soubor pluginu a updater by soubor stáhl nebyl by potřeba žádný souhlas autora. Nebo se pletu?
Pokud autor pluginu v databázi vyplní URL pro stažení balíčku s pluginem, tak tím dává souhlas jeho automatické distribuce pomocí Updateru. Nemohu však bez svolení autorů tuto URL vyplnit za ně nebo pluginy hostovat na svém serveru a distribuovat je z něj.
stepand76 wrote:V okně updateru (a tedy i v databázi) by se hodilo mít i nějaký krátký popis pluginu (asi počítat s možností více jazyků).
Přestože Salamander zobrazuje v Plugin Manageru název a popisek pluginu, tak ty nejsou ostatním pluginům (Updateru) dostupné. Název s popiskem jsou dodány Salamanderu pomocí CSalamanderPluginEntryAbstract::SetBasicPluginData2(...) a můžou pocházet odkudkoliv. Není tedy v silách Updateru, aby bez rozšíření Plugin Interface (SDK), tyto řetězce z nainstalovaných pluginů získal :(

Pro nenainstalované pluginy bude popisek a další doplňující informace staženy z webu. Pravděpodobně dodatečně po výběru konkrétního pluginu a ne součástí hlavní manifestu.

Kdyžtak moje ICQ pro rychlejší komunikaci: 143-384-547
Raptor

Post by Raptor »

Pustil jsem updater, vidim ze ftp plugin nemam aktualni, kliknu na update, stahnu novou verzi, dam do AS adresare (prepisu starou verzi), spustim znova updater a nic se nezmenilo.
Attachments
updater.jpg
updater.jpg (28.05 KiB) Viewed 18311 times
User avatar
stepand76
Plugin Developer
Plugin Developer
Posts: 455
Joined: 16 Apr 2007, 21:22
Location: Pardubice, Czech Republic

Post by stepand76 »

zarevak wrote:
stepand76 wrote:Ano SubWCRev používáme. Používám to i ve svých pluginech.
Tvůj JSON Viewer:
- FILEVERSION resource: 0.3.0.18 - tak zobrazuje verzi standardní Windowsí Properties dialog
- About dialog: 0.3.0, Revision 238 - k této hodnotě se Updater nedostane :(
Pouze jsem konstatoval, že SubWCRev používám i v pluginech, neříkám, že jako součást verze.
User avatar
stepand76
Plugin Developer
Plugin Developer
Posts: 455
Joined: 16 Apr 2007, 21:22
Location: Pardubice, Czech Republic

Post by stepand76 »

zarevak wrote:
stepand76 wrote:V okně updateru (a tedy i v databázi) by se hodilo mít i nějaký krátký popis pluginu (asi počítat s možností více jazyků).
Přestože Salamander zobrazuje v Plugin Manageru název a popisek pluginu, tak ty nejsou ostatním pluginům (Updateru) dostupné. Název s popiskem jsou dodány Salamanderu pomocí CSalamanderPluginEntryAbstract::SetBasicPluginData2(...) a můžou pocházet odkudkoliv. Není tedy v silách Updateru, aby bez rozšíření Plugin Interface (SDK), tyto řetězce z nainstalovaných pluginů získal :(

Pro nenainstalované pluginy bude popisek a další doplňující informace staženy z webu. Pravděpodobně dodatečně po výběru konkrétního pluginu a ne součástí hlavní manifestu.
Podle mě by updater měl vždy používat pouze popis pluginu z databáze (a nejen pro případ, že plugin není nainstalovaný).
User avatar
zarevak
Plugin Developer
Plugin Developer
Posts: 789
Joined: 04 Feb 2006, 16:49
Location: Prague, Czech Republic

Post by zarevak »

Raptor wrote:Pustil jsem updater, vidim ze ftp plugin nemam aktualni, kliknu na update, stahnu novou verzi, dam do AS adresare (prepisu starou verzi), spustim znova updater a nic se nezmenilo.
zarevak wrote:Dalším omezením tohoto postupu je, že případný aktualizovaný plugin se před svým načtením do Salamandera stále schovává pod starým číslem verze. Pokud se jedná o málo využívaný plugin, pak neaktuálnost jeho verze může updater hlásit docela dlouho.
zarevak wrote:... tady by se hodilo, aby Updater byl schopný plugin odnačíst (Unload) a znovu načíst. Bez jeho načtení totiž Salamander neaktualizuje čísla verzí a obnovení seznamu nepomůže.
Dvakrát jsem o problému psal, ale asi se musím naučit psát kratší příspěvky, které si aspoň někdo přečtě 8)
User avatar
SelfMan
Posts: 1142
Joined: 05 Apr 2006, 20:51
Contact:

Post by SelfMan »

Raptor

Post by Raptor »

zarevak wrote:
zarevak wrote:... tady by se hodilo, aby Updater byl schopný plugin odnačíst (Unload) a znovu načíst. Bez jeho načtení totiž Salamander neaktualizuje čísla verzí a obnovení seznamu nepomůže.
No to jsem cetl, ale bral jsem to tak ze se verze neaktualizuje pouze pokud je plugin nacteny, ale ja ho nacteny nemel, k loadu nikdy nedoslo. Mam to chapat tak, ze verze je nekde nactena pri startu AS a updater ji cte z tama? Protoze pak bych musel logicky provest Load a Unload aby se to projevilo.
Post Reply