I noticed System Admin (commercial license) module has, like happens for others modules, a dedicated change log Wiki page here which should report version’s change log but, that page, is locked at 2.11.0.5 version of July 2013.
System Admin received frequent updates during last two months (at least, AFAIK in my FreePBX Distro 4.211.64 system…):
2.11.0.7->2.11.0.8->2.11.0.10
and, just during the last two days:
2.11.0.10->2.11.0.13->2.11.0.19
Is it possible to have System Admin’s change log updated accordingly?
Maybe I’m not able to deeply looking for but I really wasn’t able to find any relevant change log neither using the CLI command /var/lib/asterisk/bin/module_admin info sysadmin, which reports only the same data available into the module.xml file, nor examining the Wiki or other official sources like, as example, FreePBX SVN here.
Will be then interesting, if possible, also to have available some informations about the change log (and relationship with the above cited System Admin module) of the sysadmin (2.6.1) RPM available here.
All modules have a change log in them in module admin. When you see a big jump in version like sysadmin did the last few days and no real new entires in the changelog the jump is because of internal testing. With commercial modules we have to do a internal publish to test since they are all obfuscated code. So it can jump 4-5 numbers
Hi Tony, yes I understand what are your challenges (internal software development and testing) but my question was more focused in learning (if it’s possible) what’s happening behind the scenes of a module that has a change log, as reported below, which is not self-explanatory.
I mean…if an average user take the time to look for and read the Change Log of the System Administration module like I’m doing now:
2.11.0.19 Packaging of ver 2.11.0.19
2.11.0.18 Packaging of ver 2.11.0.18
2.11.0.17 Packaging of ver 2.11.0.17
2.11.0.16 Packaging of ver 2.11.0.16
2.11.0.15 Packaging of ver 2.11.0.15
you would easily agree with me that sort of information is practically useless (because writing “X.Y Packaging of X.Y” is a clear semantic recursion) and generates a sincere curiosity.
Would instead be nice to read something tangible (as happens for other type of modules, like DHADI as example for which you learn what’s happening between major/minor build versions).
Is there a reason why for SysAdmin module things are managed in this way (and the Wiki is not updated)?
The reason is this happens more often with encrypted modules is because we have to test then when they are encrypted. Therefore we run a simple -b option on our compile scripts that just bumps the version number. It’s really for ‘testing’ like Tony said so adding the word ‘testing’ to the process would add another 1-2 minutes to the whole process.
…I bet 1 or 2 seconds not minutes…but, no matter, so this mean that, basically, when the module is ready to go (tagged General Available to use a common known jargon) then your compilers scripts write (for that specific Build) relevant changes as per tracking version system (which is the expected “Log of Changes”).
Isn’t it?
Just one question that arise from what you told.
You repeated “for testing” sentence so many times to justify, this is what I understood, the way change log is (or is not) generated.
Right?
At this point, I’m asking straight: should be a good practice to avoid updates of anything (modules) which is not definitely tagged with a readable change log? or, in other comparable terms, should be a good practice to avoid any updates of anything you consider (in a implicit way) released mainly for internal/external testing between G.A. releases?
Despite I always be curious enough to read Change Logs (when available) I never spent much attention on the “for testing” argument…but, at this point, a clarification could be useful considering that updating a module via GUI or via CLI doesn’t show its “testing (for Development)” / “stable (for Production)” status…leaving administrators/advanced user with a sort of question mark.
We can roll 5-30 versions internally for testing things before one of those get pushed out to the public mirrors. Its just the way commercial modules work. Sorry. Plus until FreePBX and Schmooze are on the same GIT repos which should be shortly its hard to have commit messages from our internal GIT into FreePBX SVN. But as stated this should be easier once both sides are on GIT.
And to answer your question. Commercial Modules release notes in the module all show the same thing because the commit messages are in our internal system which will change when both sides are on GIT real soon. I did not catch that the changelog in the module has none of the info we put in when we publish on our side. Sorry about that.
No worries Tony and thanks for explaining me all the process in detail.
My way of questioning was related to understand who’s who and what’s what for a very specific Module (I wasn’t absolutely speaking in general) just to be sure to learn how (and in which case) to manage updates within FreePBX/FreePBX Distro frameworks.
I’m not curious about any Commercial Module’s inside mechanisms (don’t blame me for that…I should learn how a Module works) but I am curious about how to act against updates of all sort taking account of my personal omnipresent desire (repeat: desire) to interact with systems which follow at least one or two Dieter Rams’ design golden principles (e.g. 4th rule is quite important to me: make a product understandable…at any level).