Refering to this post, I still think it would be a great benefit to have the version (and actually also the revision number) easy accessible, enabling us to discover the information just by looking at a directory listing.
I don’t know if it’s possible to have a label file added to the trunk root directory on every commit? If possible, it also should be a good idea to add a detailed parameter to Yii::getVersion().
(I use the term label file because when I was creating customized Windows CD:s there was a file in the top directory, named the same as the CD label. That way it was easy to find out the actual release type like OEM, retail, upgrade, bulk licensing.)
When you checkout yii from the svn repo, your svn client should tell you the revision; if it doesn’t, then you should probably be using another client. When you download the packaged solution, the revision will be a part of the file name (yii-1.1.6.r2877.tar.gz).
That should take care of your concerns with regards to the revision number.
No, that’s not what I mean. I can see at least two cases where what I suggested should be very useful.
Answering questions/reporting issues. No time wasted on accessing the Linux server, running svn or reading files (e.g README, .svn), trying to discover which very revision I’m on (I work from a Windows environment using a couple of virtualized Linuxes with file access through samba).
If keeping several versions of the Framework, to immediately, at a glance, verify the version and revision (no matter what the directory name indicates).
Edit:
Hosting provider not to forget. Would be very useful to have a hidden page reporting the actual framework version/revision.
having a hidden page is not good on any development platform… as this page gives out "important" information to possible malicious users… and this is considered as a high security ristk
As for the version… you can keep the Yii framework in a folder named with the version number (for example "yii.1.1.4.r2600" instead of just "yii")…
this way you would find the version very fast… by just looking at the folder where it is located…
In my opinion, not good enough. And I think framework revision would do no little harm on any page, but let’s save our customers from that verbose info.
You could define a constant in your entry script e.g
define('FRAMEWORK_REVISION', 'r6823');
and use it wherever necessary, just update the revision number whenever you do an update.
Imagine the devs having to update the revision number in a file each time they make a commit.
E.g They are currently at revision 100. They will make a commit, to be completely accurate, they will have to update the file with the revision number to 101 before they commit. They will have to keep doing this before they make a commit each time. And if they forget to update that little insignificant detail, they will have to make another commit just to update the revision number. That’s extra work with little to no real benefit. I think it is better if you keep track of the revision number for yourself. You have a svn client to do that for you.
Also, if you are using the trunk version, then we would expect you to be up to date before reporting an issue to make sure the issue wasn’t already fixed in the latest revision; So that use case is not really a valid one.
Of course this should be automated. (I don’t know if it’s possible to run a script as part of a commit.) The file can be left empty. Revision number should be part of the filename as well as some identification so the previous file can be removed.
