latest.xml is bigger because it has more information. As a bonus, it's also parseable by RSS readers.
Removing the version number from the changelog filename makes sense because you should be keeping track of it elsewhere. The version number (of the zip file) is in both the xml/rss file and the url of the downloaded zipfile. Currently, there's no way to tell the difference between Grid-r27331.1.zip and Grid-r27331.2.zip from looking at Changelog-Grid-r27331.txt because the only difference is that there were libs updated and the Changelog-Grid-whatever is the svn changelog for Grid, not its libs. Don't use the changelog filename to keep state for your updater, creating a Interface/MyAddon/.myupdater file with the version number (of the latest zip file downloaded, or keeping state in any other way) is really the way to go.
To re-iterate: svn revision ~= zipfile version ~= addon version.
With this change will it be possible to clean up the strangeness that is the meta-packages (a la !!!StandaloneLibraries)? Could they either list out the packages they contain in the latest.xml itself or be removed entirely by changing latest-noext.xml to list all required externals (and versions thereof) for each package and letting the Updater apps work it out themselves?
Are you going to be writing the code?
If I ran windows or used C# I would be more than happy to help write the code, but as it stands, no. :)
I don't mean to criticize the packages, they made sense with the old structure. However, now that updaters are intended to use the XML files mentioned above, which are far more robust than the old descript.ion and latest.txt files, it seemed like it would be a good time to request the missing data that necessitated the packages in the first place. Having the externals listed in the XML should be much easier to deal with from the perspective of an updater app than having to run batch files (or simulate running batch files) and shuffling all the directories around (transition aside). They could leave the packages there for compatibility reasons, but it would no longer be necessary to actually download them if the data is in the XML.
Removing the version number from the changelog filename makes sense because you should be keeping track of it elsewhere. The version number (of the zip file) is in both the xml/rss file and the url of the downloaded zipfile. Currently, there's no way to tell the difference between Grid-r27331.1.zip and Grid-r27331.2.zip from looking at Changelog-Grid-r27331.txt because the only difference is that there were libs updated and the Changelog-Grid-whatever is the svn changelog for Grid, not its libs. Don't use the changelog filename to keep state for your updater, creating a Interface/MyAddon/.myupdater file with the version number (of the latest zip file downloaded, or keeping state in any other way) is really the way to go.
To re-iterate: svn revision ~= zipfile version ~= addon version.
This might be a reasonable solution for updaters, but what about people who don't use updaters? Should they keep a spreadsheet of versions they have downloaded for each addon, or should they just download every single addon every time they decide to check back for updates? I'm not so much arguing for keeping the version number in the changelog so much as asking for some sort of indicator be present inside the zip file for both updaters and humans alike to tell if the latest download is "newer" than whatever they have installed. :)
Why can't the server include the version tag file then? Why do the updaters need to do that? Put latest.txt in the zip or something.
Meet me half-way here. I completey re-wrote the files script so that new zips always have new filenames and old zips are left untouched, and I created rss feeds with all sorts of metadata about dependencies and whatnot. The old changelogs weren't suitable for tracking zipfile state, neither are the new ones. Get together with the other updater authors and come up with something simple that you all agree upon.
Blind Jimmy: I save all the zipfiles I've downloaded and refer to them to determine if there's a newer version. Then again, I usually only update addons that I'm not involved with the development and/or testing of when I read about a new feature in a forum post.
Oh I agree, the new rss feeds are awesome. I'd be interested if it would be possible to discuss some tweaks to them, but those are just minute details in an otherwise remarkable upgrade. :)
so until i can upgrade to a working version of wau, what is the rss feed for seeing the latest updates/changes? i tried the latext.xml feed from /files, but did not show any changelog information. looking at the trac now, but i don't see any feeds.
Oh I agree, the new rss feeds are awesome. I'd be interested if it would be possible to discuss some tweaks to them, but those are just minute details in an otherwise remarkable upgrade. :)
Why can't the server include the version tag file then? Why do the updaters need to do that? Put latest.txt in the zip or something.
I don't understand the problem ... If you use or develop any tool to upgrade your addons it must know the version of the zip file before you download it... you wouldn't download and unpack all zip to check the included versions, would you? And since you know the version you download before you download it you can simply write your own latest.txt or whatever you want to the folder.
I use this snippet now to make a hash of all addon version using latest-noext.xml
my $content = get($config->{wowace}."latest-noext.xml");
my $data = XMLin($content);
my $items = $data->{channel}->{item};
foreach (@{$items})
{
$addons->{lc $_->{title}} = [$_->{title},$_->{'wowaddon:version'}];
}
and after unpacking i just put the version into the addons folder so I can later check it the addon needs update
open INFO, ">" . $config->{wowaddons} . "/$addon/daupdater.dat";
print INFO $version;
close INFO;
Why can't the server include the version tag file then? Why do the updaters need to do that? Put latest.txt in the zip or something.
I don't understand the problem ... If you use or develop any tool to upgrade your addons it must know the version of the zip file before you download it... you wouldn't download and unpack all zip to check the included versions, would you? And since you know the version you download before you download it you can simply write your own latest.txt or whatever you want to the folder.
I use this snippet now to make a hash of all addon version using latest-noext.xml
my $content = get($config->{wowace}."latest-noext.xml");
my $data = XMLin($content);
my $items = $data->{channel}->{item};
foreach (@{$items})
{
$addons->{lc $_->{title}} = [$_->{title},$_->{'wowaddon:version'}];
}
and after unpacking i just put the version into the addons folder so I can later check it the addon needs update
open INFO, ">" . $config->{wowaddons} . "/$addon/daupdater.dat";
print INFO $version;
close INFO;
I know how to do it. I just dont think that the updater should maintain the version tag. The zip is a product of the script, and therfore the script shuuld provide version info.
but since the zips including externals get more often updated then the noext zips it would create more confusion in my eyes.
The confusion is already there. Its just a matter of who maintains it. A bunch of non-standard "version tag files" each updater doing its own thing, or one standard one provided by the server. That seems like the logical choice (for the zip file version)
as long as your updater only updates addons from files.wowace.com you could as well use a file from the server but there are updaters that also update from curse and wowi and then you would have the file from the server and from the updater in your addons directory.
maybe you also want to store additional configuration by addon ( like my supply&demand script that adds toc entries like "## X-S&D-InRaid: true" after update to some addons) that would also require an additional file.
as long as your updater only updates addons from files.wowace.com you could as well use a file from the server but there are updaters that also update from curse and wowi and then you would have the file from the server and from the updater in your addons directory.
maybe you also want to store additional configuration by addon ( like my supply&demand script that adds toc entries like "## X-S&D-InRaid: true" after update to some addons) that would also require an additional file.
Still no good reason to purposfully leave out a version indicator in the zip. Perhaps, im just burnt out.
I don't get the point of this request. In first point you get this service for free and the server is run by this team. If they think it is better for any issue to change the log structure, it's fine for me. Why do they have to go back? Because some people are too lazy to use other sources for the changelogs?
I think the RSS and Google Option is more than fine, the rest should be, how the whole community structure is served best.
I don't get the point of this request. In first point you get this service for free and the server is run by this team. If they think it is better for any issue to change the log structure, it's fine for me. Why do they have to go back? Because some people are too lazy to use other sources for the changelogs?
I think the RSS and Google Option is more than fine, the rest should be, how the whole community structure is served best.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumlatest.xml is bigger because it has more information. As a bonus, it's also parseable by RSS readers.
Removing the version number from the changelog filename makes sense because you should be keeping track of it elsewhere. The version number (of the zip file) is in both the xml/rss file and the url of the downloaded zipfile. Currently, there's no way to tell the difference between Grid-r27331.1.zip and Grid-r27331.2.zip from looking at Changelog-Grid-r27331.txt because the only difference is that there were libs updated and the Changelog-Grid-whatever is the svn changelog for Grid, not its libs. Don't use the changelog filename to keep state for your updater, creating a Interface/MyAddon/.myupdater file with the version number (of the latest zip file downloaded, or keeping state in any other way) is really the way to go.
To re-iterate: svn revision ~= zipfile version ~= addon version.
If I ran windows or used C# I would be more than happy to help write the code, but as it stands, no. :)
I don't mean to criticize the packages, they made sense with the old structure. However, now that updaters are intended to use the XML files mentioned above, which are far more robust than the old descript.ion and latest.txt files, it seemed like it would be a good time to request the missing data that necessitated the packages in the first place. Having the externals listed in the XML should be much easier to deal with from the perspective of an updater app than having to run batch files (or simulate running batch files) and shuffling all the directories around (transition aside). They could leave the packages there for compatibility reasons, but it would no longer be necessary to actually download them if the data is in the XML.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis might be a reasonable solution for updaters, but what about people who don't use updaters? Should they keep a spreadsheet of versions they have downloaded for each addon, or should they just download every single addon every time they decide to check back for updates? I'm not so much arguing for keeping the version number in the changelog so much as asking for some sort of indicator be present inside the zip file for both updaters and humans alike to tell if the latest download is "newer" than whatever they have installed. :)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMeet me half-way here. I completey re-wrote the files script so that new zips always have new filenames and old zips are left untouched, and I created rss feeds with all sorts of metadata about dependencies and whatnot. The old changelogs weren't suitable for tracking zipfile state, neither are the new ones. Get together with the other updater authors and come up with something simple that you all agree upon.
Blind Jimmy: I save all the zipfiles I've downloaded and refer to them to determine if there's a newer version. Then again, I usually only update addons that I'm not involved with the development and/or testing of when I read about a new feature in a forum post.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou must have missed this thread.
I don't understand the problem ... If you use or develop any tool to upgrade your addons it must know the version of the zip file before you download it... you wouldn't download and unpack all zip to check the included versions, would you? And since you know the version you download before you download it you can simply write your own latest.txt or whatever you want to the folder.
I use this snippet now to make a hash of all addon version using latest-noext.xml
my $content = get($config->{wowace}."latest-noext.xml"); my $data = XMLin($content); my $items = $data->{channel}->{item}; foreach (@{$items}) { $addons->{lc $_->{title}} = [$_->{title},$_->{'wowaddon:version'}]; }and after unpacking i just put the version into the addons folder so I can later check it the addon needs update
open INFO, ">" . $config->{wowaddons} . "/$addon/daupdater.dat"; print INFO $version; close INFO;-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI know how to do it. I just dont think that the updater should maintain the version tag. The zip is a product of the script, and therfore the script shuuld provide version info.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe confusion is already there. Its just a matter of who maintains it. A bunch of non-standard "version tag files" each updater doing its own thing, or one standard one provided by the server. That seems like the logical choice (for the zip file version)
maybe you also want to store additional configuration by addon ( like my supply&demand script that adds toc entries like "## X-S&D-InRaid: true" after update to some addons) that would also require an additional file.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumStill no good reason to purposfully leave out a version indicator in the zip. Perhaps, im just burnt out.
Bring back old change logs.
I think the RSS and Google Option is more than fine, the rest should be, how the whole community structure is served best.
User feedback ;)