[tamt]

You are missing the whole point here. The thread is not about delivery of patches, it is about version control. We got a eval version of the SmartGWT SDK into our product stream.

While tracing down the issue, it was discovered there is no traceability of the Isomorphic software back to the manufacturer (which is you guys). As Isomorphic support has indicated, you currently expect the customer (us) to manually mange the traceability and versioning of the Isomorphic software ourselves (the overall manual operation and the lack of traceability of the SDK delivery mechanism is probably why we got an eval copy leaked into our source control in the force place).

The concern with this is: ISO 9000-3, 4.8 Product Identification and Traceabilty

Based on the discussion on this thread, it is currently not possible to identify and traceback with accuracy the Isomorphic software back to the vendor (you guys).

Having the customer (us) hack in a standards compliant version control scheme for Isomorphic is a large overhead on our part and most likely not accurate or audit passable since we are black box proxying a version control scheme on software we don't even control or own.

Once again, we don't need any changes to our CM process since it is ISO compliant already. What we are having issues is the SDK deliverables that we get from Isomorphic are not ISO compliant.

[Isomorphic]

No, delivery of patched builds does not introduce issues with ISO's requirement of traceability. Nightly builds have a version - that the version includes a date stamp does not make it "untraceable".

Once again, if you need help implementing ISO standards around our builds, or you would simply like to discuss your personal interpretation of the ISO standard further, please approach our consulting arm about such a project.

[tamt]

Dear Isomorphic Support:

We are not going to pay for improving and fixing Isomorphic CM and distribution processes. Especially when these changes will all be on your end and it will not even touch our own processes. Here is a quick assessment of your issues (which we will not charge you a consultation fee and we are doing it out of goodwill).

The current issues for traceability and versioning that that we see include:

1. The release notes do not indicate which version is your initial base load for the SDK release (which I believe you guys call final release).

2. Subsequently, your fix list does not detail which exact build/load introduced the fixes. Eg. as patches come along, your fix list should be a history list starting with your base load version, and incrementing with entries on a per patch basis detailed by version by version.

3. Your release note can also solve the traceability issue of clearly identifying the build which your zip deliverable is providing. The version tag of the build for the product you are delivering should be part of the introduction or you could use the fact as the last entry in your history/fix list should indicate the load that your zip deliverable is packaging.

4. You are using the same package naming for the SDKs for multiple variants of the SDK product. You cannot easily trace your distribution package by simply "looking at it". For example, SmartGWT full version eval, SmartGWT non-eval Enterprise all have the same distribution filename: smartgwtee-3.1p.zip.
You guys don't seem to have this issue with your SmartClient software where the distribution filename clearly lists the version and type of distribution. For example, here are the distribution zip file names when I click the eval and non-eval versions of the SmartClient:

SmartClient_v83p_2013-01-23_Evaluation.zip

SmartClient_v83p_2013-01-23_Enterprise.zip

See how easily identifiable and traceable the convention is for the SmartClient. The end customer can easily identify the distributable and place it in their own source control.


5. You are using the same version strings for multiple products in the code itself:

From the Smartclient distribution:
isc.version="v8.3p_2013-01-23/Enterprise Development Only";
isc.versionNumber="v8.3p_2013-01-23"

From the SmartGWT SDK distribution:
isc.version = "v8.3p_2013-01-21/Enterprise Deployment";
isc.versionNumber = "v8.3p_2013-01-21";

See that the isc.versionnumber is the same format and the only different between the isc.version string is Deployment Only and Deployment. Your customers cannot easily trace to see if they have SmartGWT SDK or SmartGWT Client. You need to clearly identify on your version strings whether the product or distributable is either the SmartClient distribution or SmartGWT Full SDK deliverable.

6. The version strings in the distribution package does not have an easy and clear linkage between the SmartGWT SDK package and the version string. You noted that someone can look at a blog for this, however, this should be in the documentation in the zip distribution package that you distribute. At least have a link in something like your release notes detailing that the customer should look at your blog for versioning information.

7. There is no clear explanation detailing the isc.version string format. Specifically the field that has "Enterprise Deployment" etc. Your build page expalains the v.X.X{letter} format, however, doesn't detail the rest of the isc.version string.

I don’t know if Isomorphic is a Windows or Linux shop. However, if you guys are familiar with Linux, the rpm package mechanism already enforces what I have stated above (it is just basic versioning and traceability 101). The rpm package is open source and even provides md5 support to ensure that your distribution is not tampered with (helps protects you, the supplier, from wrongful litigation). Have a look at that to see what people in the open source community has been doing for years on the Linux side.

[Isomorphic]

You are making a "mountain out of a molehill" as they say.

If you'd like the filename to show the version, rename the file or place it in a folder named after the version: problem solved.

The builds themselves are already completely unambiguous as to version, as we've explained.

Your #5 is just incorrect, the version number is the same, the edition of the product is different, hence the overall version is different. So the information is exactly right, and matches how other software with different editions reports versions (such as "Express" versions of databases and similar products).

It's true that we do not include release notes for patch builds, for the simple reason that it would be exceedingly rare that this would be useful in the modern era of the web. If a user encounters an issue, they are already Googling or searching this forum for answers, so they will encounter the discussion indicating the bug is fixed. Release notes usually do not provide enough information for a developer to tell definitively that something is *not* fixed and hence avoid the effort of trying out a new build.

Our version string format is self-explanatory given the license levels and the material at smartclient.com/builds. We don't document a formal way of parsing it because doing so is not supported - we may have good reasons to modify the format in the future.

We are not any kind of "shop" - that's frankly a bit of a dated notion in the era of web software, when Linux, Mac, Windows, other Unix and mobile platforms are in the mix - but there is nothing about our versioning scheme that's incompatible with rpm (or with more relevant tools such as Maven).

So to sum up once more: we do not present any obstacles or any extra effort to ISO compliance. There is no ambiguity about versions, or about what is the stable release or what we recommend using.

You've expressed a preference for release notes for patch builds, versions in more accessible locations in the package, perhaps a reliably parsable version string (or subset of it). That's all fine, and you can consider taking advantage of our various services to have such enhancements added if they are important to you.

If you don't want to engage our services for enhancements like this, that's fine - but as we do not have other people (inclusive of ISO shops) making similar requests, we will be pursuing enhancements that multiple people actually want instead.

[tamt]

Responses below with context from last message:

“If you'd like the filename to show the version, rename the file or place it in a folder named after the version: problem solved.”
- It will not solve the problem. This is how this problem started in the first place. We were manually changing file names for your SmartGWT SDK deliverables and this does not work. At the end of the day, we could not verify if we downloaded the wrong file, or the wrong file was posted up on your web page since things were not versioned at the source (Isomorphic). This fragile scheme is highly dependent on the person who is downloading the file from isomorphic that they didn't click on the wrong link. There is no way to determine what the deliverable is by just looking at the file name of the zip file that is downloaded.
- I don’t understand why you just don’t do the same justice that you do for the SmartGWT SDK versus the SmartClient distributable. If you produced the same file name format for the smartgwt deliverable, then we would not of had the issue in the first place since there is no manual step on the customers part to track the versions of the Isomorphic distributable. Also, it will clearly indicate if the file was posted wrong on the web page or not.


“The builds themselves are already completely unambiguous as to version, as we've explained.”
- Your customers need to pull a java script file out of a jar file for the SmartGWT deliverable to determine the version of deliverable from the packaging. This is an overhead.

“Your #5 is just incorrect, the version number is the same, the edition of the product is different, hence the overall version is different. So the information is exactly right, and matches how other software with different editions reports versions (such as "Express" versions of databases and similar products).”
- The SmartClient deliverable zip and the SmartGWT deliverable zip contain different content. SmartClient packages smartclientRuntime and smartclientSDK. The SmartGWT deliverable packages apache-ant-1.71, doc, lib, samples, selenium, etc. These deliverables are different products since you charge different prices for each. Isomorphic support indicated that the way to determine which deliverable zip package you have is to look at the isc.version string. Basically the Smartclient zip deliverable package and SmartGWT SDK deliverable package has the same isc.version string. As I showed on the example in a previous message, both the SmartClient Enterprise deliverable and SmartGWT deliverable seem to have the same version string. The only difference is the word “only” in the string. Are you saying the word “only” is how we distinguish between the Smartclient Enterprise product and the SmartGWTEE Enterprise product?

“It's true that we do not include release notes for patch builds, for the simple reason that it would be exceedingly rare that this would be useful in the modern era of the web. If a user encounters an issue, they are already Googling or searching this forum for answers, so they will encounter the discussion indicating the bug is fixed. Release notes usually do not provide enough information for a developer to tell definitively that something is *not* fixed and hence avoid the effort of trying out a new build.”
- Customers like us (and our customer base for our product) is only interested in picking up patch loads that fix their issue, and not go to the latest load. Even in today’s latest and greatest gadgets like Android devices, you will see examples where picking up the latest load is not the best thing since there may be bugs introduced by some other patches. People would look at the release notices and see which load delivered what fixes and decide which sub-release Android load to go to.
For example, how are people going to roll back an Android load if there are not proper release notes indicating which version of the loads delivered what. I don’t see any difference between the example of Android and Isomorphic software. Customers need intelligent information to determine which load to pick and going to the latest is not always the preferable option.

“Our version string format is self-explanatory given the license levels and the material at smartclient.com/builds. We don't document a formal way of parsing it because doing so is not supported - we may have good reasons to modify the format in the future.”
- It was the recommendation of Isomorphic support to look at the isc.version JS expression in ICS_core.js to determine that is the version of the zip deliverable which is being delivered to the customer. You are burning our ears right now telling me Isomorphic support is giving us “non-supported” solutions. In fact, Isomorphic support has indicated in this thread to parse that string in our code.
Please tell us the supported method to determine the version and type (eg. eval or non-eval) of the smartgwtee-x.xp.zip deli verable from the zip package itself. Also what is the supported method of determining the version of the SDK we are using from code.


“We are not any kind of "shop" - that's frankly a bit of a dated notion in the era of web software, when Linux, Mac, Windows, other Unix and mobile platforms are in the mix - but there is nothing about our versioning scheme that's incompatible with rpm (or with more relevant tools such as Maven).”
- All we are stating here is versioning practices has not changed for 30+ years and is still being used from Microsoft, Apple, Google, etc. RPM is just and easy example of seeing what people are doing if you guys need a reference to look at.

“So to sum up once more: we do not present any obstacles or any extra effort to ISO compliance. There is no ambiguity about versions, or about what is the stable release or what we recommend using.”
- I have clarified above that there is ambiguity about versions.


“You've expressed a preference for release notes for patch builds, versions in more accessible locations in the package, perhaps a reliably parsable version string (or subset of it). That's all fine, and you can consider taking advantage of our various services to have such enhancements added if they are important to you. “
- Yes versioning and tractability on software that we purchase and include in our product is important to us (and obviously is important to any of your customers). However, having us pay for processes that should be there in the first place is outrageous and insulting.

“If you don't want to engage our services for enhancements like this, that's fine - but as we do not have other people (inclusive of ISO shops) making similar requests, we will be pursuing enhancements that multiple people actually want instead.”
- Honestly, I don’t see how an ISO shop would let this go. To us, they are either taking a hit and doing the versioning for Isomorphic and living with any mistakes that can happen, or they are only using the product internally and not on a public product. ISO doesn’t apply to internal tools or applications.

[Isomorphic]

It's very unfortunate that you or one of your colleagues made a mistake and checked in an Eval copy. However the Evaluation link was clearly labelled and the Eval version indicated in the Developer Console whenever you use the software.

So this is simply a mistake on your part that you should try to avoid repeating.

The rest of this is a series of inapt analogies and reiteration of previous asked and answered questions. We really cannot be expected to answer the same question 3+ times, or to chase down incorrect analogies, so this thread is now closed. We would invite you to revisit previous responses very carefully (on your own time of course) in order to answer the questions you have re-raised in your last post.