Ticket #970 (closed defect: fixed)
Add Aegisub version to update checker URL.
| Reported by: | verm | Owned by: | nielsm |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.1.8 |
| Component: | General | Version: | devel |
| Severity: | minor | Keywords: | |
| Cc: | Platform: | All | |
| Sub Component: |
Description
Having a revision isn't enough for us to tell what version is requesting an update check as the revision will always be the latest copy of the source. These could be anything, generally people won't be making their own builds in release mode however if we take too long to release there many be some that do and pass that build around..
Change History
comment:2 Changed 2 years ago by nielsm
Would it be better to use a "branch identifier" or to use the version number? (Should we say "trunk" or "2.2.0" for current trunk builds?)
comment:3 Changed 2 years ago by verm
Well, released versions will always have a static revision.. so revision + version should be fine. Unfortunately relying on anything else wouldn't be possible since they can be changed (release/debug build identifiers etc)
comment:4 Changed 2 years ago by verm
Come to think of it we should add the operating system family as well. WX has a good function for this that we can use. This will return very generic names which doesn't involve anything privacy-wise as a web browser volunteers this information anyway.
comment:5 Changed 2 years ago by nielsm
So what do we actually want in there, and how are we going to collect/pull it?
I think revision and branch (or tag or trunk) the version was built from, those together will always uniquely identify what version is in question and makes it clearer where the code was sourced from.
For the branch part, it does blur towards "version number", since it probably is best to not use the raw branch names, for our own sake. The branch names I imagine would end up as:
- trunk (obviously the trunk, by definition unstable)
- 2.1.8-dev (the 2.1.8 branch, not final)
- 2.1.8 (2.1.8 when it has been tagged and released)
- possibly exp or similar as a general name for anything experimental that isn't trunk
Another question is where the information should be sourced from. I suggest having a file in the root of each branch that just names it.
As it is now, I believe the update checker is disabled everywhere but Windows so it wouldn't make much sense to send platform information along either way.
comment:6 Changed 2 years ago by verm
Well, we should pass actual build information as values, for instance update.txt?version=x.x.x&rev=x&release=(0|1) I don't see any reason to add -dev if it's a dev version or not. Just identify it if it has been built in release mode or not. Trunk will always have a version as well, so identifying it as 'trunk' won't work as trunk can be any version. Just use the version in the version being buit.
I was planning on fixing the update checker on both unix and osx before release.
comment:8 Changed 2 years ago by nielsm
- Status changed from new to closed
- Resolution set to fixed
The query string from 2.1.8 is now rev=%d&ver=2.1.8&rel=%d&os=%s with rev being SVN revision, ver being a static string, rel being a boolean (0 or 1) indicating whether FINAL_RELEASE was defined and os a string indicating the general OS type, also version in the case of Windows and Mac OS X.
For trunk we should develop a new version checking system that doesn't use the current latest.txt format, but be more flexible. For that reason, the 2.1.8 statistics collection is implemented using least effort including the hard-coded version number string. A new ticket should be opened for a new version checking system.
On a note, the current version checker does UI stuff from a worker thread which is known to cause crashes on wxGTK and wxMac, I believe the menu item is removed in all but Windows builds.
Err this should have been milestone:2.1.8.