Question on Appian Common Objects package

Certified Lead Developer

Appian Common Objects is not listed as Add-ons for 7.10 and 7.11. The last time the documentation page was updated was nearly a year ago, 5 February 2015: forum.appian.com/.../Appian_Common_Objects_Application

Is the package no longer recommended?

OriginalPostID-189010

OriginalPostID-189010

  Discussion posts and replies are publicly visible

Parents
  • Agreed, a reference/link would be helpful. We upgraded our production servers this weekend from 7.6 to 7.11 and we just 'assumed' that the older 7.5 R2 common objects were supported and current (we tested our code base but didn't specifically target the common objects).

    As a side note, there are a lot of commonly used shared components available and knowing the testing status of these for each version would be helpful. It puts the developers in an awkward bind when we need or want to add functionality to Appian because using the shared components comes with risk. I like the ability to add functionality to Appian that others create, but the overall lack of documentation & maintenance on them is worrisome and slows down our upgrade cycle significantly (more hours & risk for each upgrade).

    1) for new and older rarely updated/tested/commented components that lack a proven track record we take a risk using them because they may break in future versions with zero support or updates

    2) 6-12 month old components that have had a few updates or postings may be only slightly maintained by random people or Appian staff and will probably work and be less risky

    3) some components appear to be popular and are actively updated and hence presumably 'tested' (unofficially or otherwise) and will be supported by someone. If they are popular and maintained, why not push to add them (or similar functionality) to the base Appian package so that they can be used without fear? The 'cost' of maintenance is thereby spread over a larger user base. If the components lack robustness (support for languages, locality, etc.) then maybe just assign someone internally to perform testing & light maintenance while coordinating with the people who wrote the code.

    As of January 26, 2016, 3 business days after the 16.1 update was released:
    271 components listed, no filter for latest compatible version newer than 7.2 available
    Last 30 days - 6 updated, zero list 16.1, only 3 list 7.11
    Last 90 days - 27 updated, zero list 16.1, only 3 list 7.11, 3 don't even list 7.10 (they show 7.9 or 7.8)
    Last 180 days - 63 total components updated, 23%
Reply
  • Agreed, a reference/link would be helpful. We upgraded our production servers this weekend from 7.6 to 7.11 and we just 'assumed' that the older 7.5 R2 common objects were supported and current (we tested our code base but didn't specifically target the common objects).

    As a side note, there are a lot of commonly used shared components available and knowing the testing status of these for each version would be helpful. It puts the developers in an awkward bind when we need or want to add functionality to Appian because using the shared components comes with risk. I like the ability to add functionality to Appian that others create, but the overall lack of documentation & maintenance on them is worrisome and slows down our upgrade cycle significantly (more hours & risk for each upgrade).

    1) for new and older rarely updated/tested/commented components that lack a proven track record we take a risk using them because they may break in future versions with zero support or updates

    2) 6-12 month old components that have had a few updates or postings may be only slightly maintained by random people or Appian staff and will probably work and be less risky

    3) some components appear to be popular and are actively updated and hence presumably 'tested' (unofficially or otherwise) and will be supported by someone. If they are popular and maintained, why not push to add them (or similar functionality) to the base Appian package so that they can be used without fear? The 'cost' of maintenance is thereby spread over a larger user base. If the components lack robustness (support for languages, locality, etc.) then maybe just assign someone internally to perform testing & light maintenance while coordinating with the people who wrote the code.

    As of January 26, 2016, 3 business days after the 16.1 update was released:
    271 components listed, no filter for latest compatible version newer than 7.2 available
    Last 30 days - 6 updated, zero list 16.1, only 3 list 7.11
    Last 90 days - 27 updated, zero list 16.1, only 3 list 7.11, 3 don't even list 7.10 (they show 7.9 or 7.8)
    Last 180 days - 63 total components updated, 23%
Children
No Data