I'm sorry to hear that we've changed something you were relying on.
Thanks, but I'd like my questions answered. How in the world can it be justified? Moreover, what cleverness prompted someone to say, "Let's take something simple and useful and add a bunch of extra processing/evaluation/limitation that will break something that has never failed to work well?"
Other 'changes' have been made reverse compatible with the updating scheme by adding new instead of reformulating existing. That is -always- good policy unless it becomes overly complex and unmanageable, and 'overly' has to mean great enough to justify breaking the work of others.
1 person found this helpful
Sorry if that response seemed dismissive, that was not my intent.
I've done a bit of research into the feature spec/test plan for this and here is what I've discovered:
The original <version> system had no restriction on the alphanumerics that could be used. This approach works fine as long as we deal with .air files. We had been using a version comparison method for alpha-numeric strings (take dots into consideration etc) to compare two .air files for same application with different versions.
However, when it comes to comparing versions for the native installers corresponding to those AIR applications, it doesn't work fine. We had been using approximate methods of mapping version tag to the format of version strings on different platforms. For eg., one commonly used method is removing all the non numeric characters from the version string. In this case, suppose the versions of an application are 2.0alpha and 2.0beta, both will have "2.0" as their version in the native package and hence would not be treated as an update.
Same issue came up when we were dealing with native packages for Android - and so it was decided that it is the right time to get our versioning updated to something more industry standard that works across platforms reliably.
You can use the optional <versionLabel> to provide a easy-to-read verison for your users.
I think I've been in your shoes before and understand the annoyance of code changing underneith you that breaks a reliable system. I ran into the problem of the switch from <version> to <versionNumber> when updating old test media myself. There was some discussion at the time of leaving <version> in, as-is, as a fallback, but in the end the decision was to go with the new system exclusively to make things less confusing. (I imagine you probably disagree with that last bit, I'm not sure that I would disagree with you as an external developer.)
Though I'm not sure you need this, I'll leave this pseudo-code for how a developer can transition from the 1.x/2.0 to 2.5+ framework:
UpdateFramework was updated to take into account this change and to allow applications to update to 2.5 from any previous version.
In order to update, from 1.x/2.0 to a 2.5 application, an intermediate update is needed, in which only the update framework is updated to the version included in AIR 2.5.
This is how it works:
- Application has <version>1.0</version> and wants to update to namespace 2.5 and <versionNumber>1.1</versionNumber>
- Developer updates UpdateFramework to version 2.5 (included in AIR 2.5). Updates version to <version>1.0.1</version>. Change the update descriptor location to a new file (preparing for 2.5 namespace and to allow old application to always go through the intermediate version).
Uploads new version to update site.
- Application updates itself to 1.0.1
- Developer updates application to namespace 2.5 and <versionNumber>1.1</versionNumber>. Push the update at the new location pointed by the new update site included in 1.0.1
- Application updates to 1.1
Thank you. I appreciate the comprehensive answer, and yes... I got a little annoyed that the response from Adobe after 10 months (ok.... it will be tomorrow *chuckle*) was so... dissatisfying.
If I read it all correctly, the decision... in the end... was to deliberately and knowingly break things with no real transitional easing, and I can't countenance that and am in no way mollified on that account, but I do appreciate the complexity of the nut Adobe was seeking to crack, and what's done is done. We simply apologized and asked our users to uninstall and download a fresh installer. I'm hoping that my case was something rare and unusual. Other people like revision scheming with significance assigned... myself, it's enough know that yesterday's date can never postcede tomorrows *chuckle*
Your transition scheme is a good one and I wish I had either run across some documentation suggesting it, or that it had occurred to me, and much to my chagrin as it has provoked an 'oh duh' moment and I like to fancy myself something of a MacGyver. (Having your friends call you such doesn't make it so when you can't figure out how to fix the thing with the toothpick and chewing gum in your pocket when someone else can easily do so.)
Thank you Roymeo.
// Christian - of the holy-order of the run-on sentence
Adobe has never learned (but then, neither has any other company I've run across...)... the place for links like that is in error messages and standard doc updates that are -pushed- to subscribers...not the equivalent of 'this knitting pattern makes no sense' 'this equation doesn't work' 'this recipe calls for salt but the author probably means sugar' type of book publisher 'errata' website where if you're lucky and if you have the time to waste you can go find the solution to someone else's mistakes. This is not physical print, so it's so much the easier.
The fact that such an article exists means that
- the problem was identified
- the problem was deemed significant
- a workaround was developed (most likely -after-, not -before- the damage was done... though item #1 was, from the sound of things existent before the damage was done)
Companies, I feel, in good faith owe it to those who pay subscription/licensing fees and act as evangelists by using their technologies and gaining them greater market foothold/significance, to make an effort to be as pro-active and preemptive... but of course I'm seeing this from the perspective not of the tech dev, but the dev using the tech. Anyways. Thank you for your time.
(Just in case I'm unclear... I did extensive searching at the time and came up with neither this resource, nor someone sharing the earlier transitional solution you shared [I really -wish- I'd been clever enough... spilt milk et. al.,])
Cheers... thank you for the balm of hearing that someone at least does care and not all frustrations dissipate into the ether as tribute to our own impotence. May your Christ-mas season be filled with blessings. // Christian