Topic Feature Freeze and Release
This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.
In Response to Newton
Cool, so after all you are doing it this way. Where are the binaries and updates uploaded to? Should I change anything regarding the name of the directory? (nightly-builds currently, isnt it.)
I noticed during a conversation with B_E earlier that perhaps the procedure described on page two:
"[...] all rows which have the same platform as the one specified in the command are deleted from the table [...] All files that have been referenced by deleted rows must be deleted by the masterserver in both cases if delete_old_files is 'yes'" [...]
should function a little bit different. The reason is, that with the current concept, it is just not possible to to create different update packages for different from-versions (= making more than two requests per update) because the rows added on the first request are deleted again on the second. This odd logic in the masterserver can't be bypassed by the build scripts. Example:
To fix this, on a new request not all rows which match the same platform should be deleted but only those which do not update to the newest version. (newest version = the version that has been given on the last request in the parameter new_version.)
I marked the change in the masterserver.pdf.
I noticed during a conversation with B_E earlier that perhaps the procedure described on page two:
"[...] all rows which have the same platform as the one specified in the command are deleted from the table [...] All files that have been referenced by deleted rows must be deleted by the masterserver in both cases if delete_old_files is 'yes'" [...]
should function a little bit different. The reason is, that with the current concept, it is just not possible to to create different update packages for different from-versions (= making more than two requests per update) because the rows added on the first request are deleted again on the second. This odd logic in the masterserver can't be bypassed by the build scripts. Example:
?action=release-file&platform=win-x86&new_version=1.4.0&file=oc-win32-1.4.0.msi&hash=1238754345<- installation file?action=release-file&old_version=1.2.4,1.2.6&platform=win-x86&new_version=1.4.0&file=oc-win32-1.2.4-1.4.0.c4u&hash=3981842046<- updates from 1.2.4?action=release-file&old_version=1.4.0a&platform=win-x86&new_version=1.4.0&file=oc-win32-1.4.0a-1.4.0.c4u&hash=456568532<- update from 1.4.0a to 1.4.0 overwrites the updates from 1.2.4 and 1.2.6
To fix this, on a new request not all rows which match the same platform should be deleted but only those which do not update to the newest version. (newest version = the version that has been given on the last request in the parameter new_version.)
I marked the change in the masterserver.pdf.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill