The TKL version number means that it was built on the same version Core. E.g. TKL LAMP v12.0 appliance is built on TKL Core v12.0. TKL Joomla v11.1 built on TKL Core v11.1...

Or did I misunderstand your suggestion?

For example the (very dated) TKL Zimbra image (which is stuck at v2009.10-2 until TKL supports 64 bit) has the same generic link to TKL Core as a current v12.0 appliance. I can see how that may be a little misleading, especially for someone new to TKL.

So (to continue using the Zimbra appliance as an example) you are suggesting that instead of:

This appliance includes all the standard features in TurnKey Core, and on top of that:

[...]

It should perhaps read something like:

This appliance includes all the standard features in TurnKey Core (same version as the appliance - check the Core changelog) and on top of that:

[...]

Or better yet (pointing to the specific changlog entry):

This appliance includes all the standard features in TurnKey Core (specifically this version) and on top of that:

[...]

What do you think?

While the immediate attempt to find a better solution is commendable, I would like to point out (in a purely informational, non-confrontational way) that Henry does not speak for all of us...personally, I always found the versioning scheme rather intuitive: The appliances are released in series. Every appliance is built on a core plus a payload. So it makes perfect sense that Turnkey Joomla 13 is the Joomla appliance of the 13th series, and thus built on TKL Core 13 - the core of the 13th series...

What's -imo- a whole lot more confusing about the versioning is that an upgrade of the Core version does not necessarily imply an upgrade of the playload, or that the payload is current in any way: To me, it is obvious that TurnKey DokuWiki 12.0 is built upon TKL Core 12...it is not obvious that, despite the fact that the Core was upgraded on 2012-08-30, the payload is from 2009. (We've had this topic before, so I understand how it comes to that, the fact is just not very clearly communicated.)

I do think Henry's suggestion is a bit verbose and kind of takes the "branding" out of it - it stops being "TurnKey Linux Something" and is turned into "Something installed on TKL". While it is subtle, it moves the name away from communicating "this is a turnkey-ready Something appliance of the TKL brand" to saying "this is Something installed on the following Linux distro: TKL". iow, there is a communicative difference between "TurnKey Joomla 13" and "Joomla version 2.5 built on Core version 13.0". The latter is no different from "Joomla version 2.5 built on Ubuntu Server version 13.04", "Joomla version 2.5 built on CentOS version 6.4" or "Joomla version 2.5 built on Debian version 6.0.7".

The focus is no longer on it being an appliance, and is instead put on the payload software being installed on a random Linux flavor. And TKL appliances are more than that. They deserve better, and the creators have earned the right to brand them.

I believe the easiest way to consolidate all three points of view in this thread would be to move the most important information of the tucked away version information page onto the main appliance page: Instead of just having the almost-pointless "Stable version: 12.0 (changelog)" line, place a table on the page which says

Click here for more information

With "here" linking to the changelog, where the detailed information can be found.

That way, the current "grand" scheme of versioning in series or waves can be maintained, TKL retains its branding, but everybody can quickly and easily get an idea of what exactly they're getting with the appliance.

Instead of your suggestion:

Joomla 2.5 build on TKL Core 12.0
Joomla 2.5 build on TKL Core 11.0
Joomla 1.5 build on TKL Core 12.0
Joomla 1.5 build on TKL Core 11.0

Why not just keep it the same as it is:

TKL Joomla 2.5 v12.0
TKL Joomla 2.5 v11.0
TKL Joomla 1.5 v12.0
TKL Joomla 1.5 v11.0

Then like I said in my original post - the TKL version relates to the Core version it is built on...

The only reason the version is mentioned in the name of the Joomla appliance (and the Drupal one too) is that there are 2 appliances using different versions of the same software. It is impossible (or at least impractical) to maintain a simple consistent naming convention and also include version numbers of software in the appliances unless there is a need to differentiate them from one another (like with the Joomla and Drupal appliances). 

To use a naming convention consistent with your suggestion Henry, what would we call the TKL LAMP v12.0 appliance?

Apache 2.2 MySQL 5.1 PHP 5.3 Perl 5.10 Python 2.6 on TKL Core v12.0?

I know what I prefer! :)

Perhaps Henry, the issue is like Carl suggests and the "Stable version: 12.0" and is too small (just above the "Turnkey Core" link) or not obvious enough?

I must admit that I quite like your suggestion Carl although it potentially also suffers from some of the same issues as Henry's. While it would work great for many (most?) of the appliances, it is desirable to have consistency and so what details do you include for the LAMP appliance? If you start including Apache and MySQL versions then perhaps that should also appear in other appliances that use Apache and MySQL? So whilst i like it, I'm still not convinced that any significant change is needed (perhaps making the version number more obvious?)

I understand where you're coming from, but I believe you are assuming a situation where you are still close to the "sweet spot" - the feature differences between debian stable custom package version and actual software stable version are minor, and the codebase is close enough to backport security issues.

Reality, however, isn't as pretty as that. Look at the Debian changelog of the stable dokuwiki package. The last change was on June 29, 2011. It's still using the Lemming branch. Since then, the project released the Anteater, Rincewind, Angua and Adora Belle branches, with Weatherwax in RC. Can you imagine that backporting security fixes to Lemming isn't a priority to them anymore?

The truth about backporting is that it has an expiration date: At a certain point, your ancient codebase is so out of sync and outdated that you'd have to maintain it as a completely separate software project. That's not feasible, so the backports just stop. As they did with Dokuwiki.

So while I appreciate the Debian projects' efforts to maintain the security of their distribution, the basic assumption that "it's from Debian stable" equals "it's secure" is a dangerous one.
I've mentioned the old Linux joke before: Debian comes in three editions: Stale, rusty and ancient. Personally, my association with the phrase "Debian packages" is not "secure" but "outdated". And that's problematic not just on the security front, but also on the feature side of things.

Not only are features a big part of end user satisfaction and efficiency, there are also feature upgrades for administrators and developers. Having an outdated API makes development pointless - why develop if you know it's not going to run on the current version and will break with the next update?
More important, however, are the administrative features and changes. Great example right now is the GitLab appliance: I'm trying to establish git as the company's source control of choice here. I'd like to install a GitLab instance to make adjustment easier for everyone. Naturally, my first choice would've been TKL, but TKL's GitLab-version is at 2.5. Even if you update the hell out of it, the latest versions you're going to get are 4.x; 5.0 is current by now, and has significantly changed the underlying architecture of the software, meaning different and easier administration for the sysadmin. If I know the current version has fewer dependencies and is easier to administrate, why on Earth would I want to install an outdated version?

Mind that the linked repository is the one linked to in GitLab documentation; it's an unsupported third party repo, so the whole "it's from Debian stable, so it's secure" mantra doesn't apply in the first place. The official installation guide propagates a whole shitload of manual work on Debian, including self-compilation of Ruby.

I understand where you're coming from, with the focus on server stability and coherence. In theory, it's a good approach to server administration. It works if you're testing your software yourself, and then compile and install your own binaries. But reality looks different. As long as you're relying on outdated, unmaintained packages, backported or not, you're no safer than somebody installing the latest versions. And the latest versions at least include fixes for all known security issues. (At least with a good project.)

Conclusively, while do I see your point, personally, I can't agree with it, and don't consider the Debian project's ancient backports and repo versions valuable enough to be stuck with them.
Therefore, knowing what I'm stuck with in advance is a big part of deciding for or against an appliance for me.

Since your suggestion for the block includes all information I included (as far as I can see), I see no issue with it. :)

While I will acknowledge that, from a security point of view, the debian version is not as bad as it could have been, I only find my opinion strengthened: Even in the "new" wheezy, the security page gives the current debian version of dokuwiki as 0.0.20120125b-2 - that's 2012-01-25b “Angua”, the most recent version of dokuwiki listed in the "old versions" section. Which starts off with the note "These releases are no longer recommended for usage and are listed for reference only."

In other words: The latest version of dokuwiki in the brand new release of debian is so old, that the project does not recommend using it anymore.

Yes, Angua was the last release marked as containing a security fix. So by applying the metric of "no unpatched published security issues", it is a safe version. But does that make it a reasonable version?
By applying the very same logic, 2012-10-13 “Adora Belle” is also a safe version: There are no unpatched published security issues.

If you use the number of known, unpatched security issues as a metric, the latest stable version of dokuwiki is 100% as secure as the 15-month-old version current with debian. But unlike Debian's ancient version, it contains several dozen additional bugfixes as well as new features and architectural improvements.

My point is: You are talking about secure software as if the fact that all known, glaring security issues have been fixed makes an ancient version of a software equal to the current version in security. For one, that is simply not the case - the latest stable of dokuwiki, for example, includes changes to the password reset mechanism, Active Directory integration and ACLs, all improving the authentication and authorization structure of the application. The current RC replaces the blowfish encryption library, because it creates inconsistent results across platforms.
Secondly and more importantly, however, the entire core argumentation of "this is more suitable for a server because it's a known stable version with all known security holes fixed" falls apart when one realizes that the latest stable version has the same patch level and is the one not deprecated by the project. Or, to phrase it differently: If, by the same metric, both versions are equally secure, but one of them is labeled "no longer recommended for usage" by the people who should know best, that is not the one one should put on his server for production use.

And all of this happens in the makebelief world of "all exploits are known" anyway. The reality is that the truly dangerous security issues are the ones not known to the project developers or the system administrators. And for protection against unknown issues, I prefer the security architecture that has seen 15 months of additional scrutiny, development and improvement, not the one the project has already deprecated.

As said before: I understand where you're coming from. I know the argumentation. I just think it's more legend than reality.
Earlier in the discussion, you said

Beyond features (and compatability with newer plugins) the most secure and stable version is the ('old') version from the repos!
This point is often lost on newbs (particularly Windows users...) as many have been trained to believe that old versions are 'bad' (have security issues) and the new version is always best...

to be frank, I think you're showing the reverse side of the indoctrination here. Just like the generic Windows user assumes the latest version of a software is always the best, without ever questioning that, you're automatically assuming the latest version will be less stable and less secure, and an old, "time-tested" version will be the better choice - without ever questioning that.

The Windows newb has faith in the application's developer.
You have faith in the debian security team.

It's the same approach, just a different deity.

You and/or the debian project are equalizing "new version" with "new bugs" and "new features", and thus not necessarily relevant to production use.
I equalize "new version" with "fixed bugs" and "improved architecture", and thus very relevant to production use.
The truth probably lies in the middle.
But no matter what the truth is, I do believe you, too, can agree that knowing what version one installs on a server is important: Be it to ensure the software is reliably ancient or to ascertain it was developed in this decade, one has to know what version it is.

And that information, that full disclosure, is what we were originally discussing.

Even if you disagree with my reasons for wanting to know at a quick glance what versions are deployed with a TKL appliance, can you agree that making it easier and more intuitive for the potential administrator to see what versions the appliance includes would be a good thing?

Your argument against an "in your face" listing was that seeing the older versions might turn off new users who don't understand the "ancient == stable" paradigm. I understand that concern. But can you truly say that conning them into installing the appliance by keeping the versions quasi-hidden is a better approach?

How many possible scenarios for that are there?

• The user sees no versions,  doesn't care, installs the appliance, and is happy.
• The user sees no versions, assumes it'll be the latest, installs the appliance, and is pissed off.
• The user sees no versions, wants to know them, doesn't find them, and is pissed off.
• The user sees no versions, wants to know them, finds them, and is happy.
• The user sees no versions, wants to know them, finds them, and is turned off.
• The user sees the versions, doesn't care, installs the appliance, and is happy
• The user sees the versions, does care, installs the appliance, and is happy.
• The user sees the versions, does care, and is turned off by what he sees.

The latter is the case you're fearing. But what you'll notice is that that is the only case where the numbers are visible that ends in sadness. All people not caring or satisfied with the versions are fine with seeing them. On the flip side, when the versions are hidden, both the people who do and don't want the latest version in their appliance are pissed off by how it is artificially made harder to get the info they want - reasonable, important information for a server installation.

You are essentially trading the happiness of seasoned administrators for the blissful ignorance of the newbs. And for what? If they never see the version they're installing, and they have no issues in production, they will never learn the lecture you are hoping to teach - they never learn they're running an old version and that that's somehow better, because it just works.

When would those who did not see the version they were installing care about it later? Only when there are problems. When features are missing that the project's page promised, when bugs are occurring that the project's forums claim are fixed. And then the sudden realization: This POS came with an ancient version!! What do they learn? Check the versions, or you might get some ancient shit that ruins your day.

Once again, the sysadmin lesson is not taught.

Sure, you can try to convince them that the deployed version is better, but how likely is it they'll agree, after the reason they noticed is that the installed version made them unhappy?

You will not teach lessons by conning people into installing something they wouldn't have wanted to install or by pissing them off later on.

Yes, telling people up front "this is not the latest version" might turn a few of them off. But it also ensures that those who do install the appliance know what they're doing, have the correct expectations, and understand the situation when there are problems in production.

How about listing the versions and placing a "learn why this version is better than the latest version" link next to it?
A bit of a polemic phrasing, but it should catch the potentially-turned-off-user's attention long enough for you to have a chance to convince him installing a four-year-old version of dokuwiki might somehow be a smart idea. ;)

Edit: On an entirely different note, the partial/pseudo-threading of this software is really annoying. If there's a commenting interface under the latest comment, I expect to be replying to that, not open a thread inside a thread. -_-
Also, unless I'm blind, the WYSIWYG interface doesn't have buttons to change the font size. (Or color, for that matter.)