Sean
It is possible to do this however you will need a workflow to run behind the scenes to create a sneaky URL with some specific elements in it to show the latest Published version of any document - i.e. the Major release.
Basically the way SharePoint manages previous version of documents is in using a set of hidden folders of all the previous versions. The first Published version of any document gets set up as this:-
http://server-name.com/subsite-name/_vti_history/512/library-name/file-name
as you can see there is an extra bit in the ( /_vti_history/512/ ) which is used to denote the first published version. So if you need to access version 1.0 put that extra bit in the URL BEFORE the library name, then paste it in a browser and see what happens. If you wnat version 2.0 of a document, you'll need to change the '512' in 1024. Version 3.0 becomes 1536, v4.0 uses 2048 and so on.
Thus if you create a workflow on your document, you can build a string using the URL of the library, and the integer from the version number, and then times that by 512, and pull the lot together and place it into a new Hyperlink field (you can make it with a 'click here for Published version' tag as well), then include that in your View. It's a bit of a work up but SharePoint hides this kind of detail from the normal way of working.
We've used it in a Formal Document Management system we developed for 2007 and 2010 versions of SharePoint (we are working on a 2013 version now) which is often used by companies looking to manage Procedures, Policies, Forms etc for ISO 9000/14000 and similar Compliance standards.
If you need further guidance, do please come back to me.
Extra guidance
Sean
You need to bring a number of things together at this and I'll try and explain what you need to establish and set it up.
- A new field (URL type) in the library that is used for the URL link to the 'Latest Published (current) document' (I'd think about using a hidden field on the document, but use it for the View display only.
- A Workflow in SharePoint Designer which only runs when the document is Published or the version ends with a 'zero' (perhaps it could run upon change, but then pauses until the Status value field hits 'Published', thus it only runs once every Publishing cycle.
- Change the appropriate View(s) and add the URL field to that
Create the Upon Change WF for the library, and in that create a VAR string builder in it which adds:
- the prefix of the (server/subsite/_vti_history/) PLUS (the Published number which will be 1.0/2.0/3.0 etc, and multiplies that by 512) PLUS a forward slash then the suffix of the library name and the file name PLUS (and this is very important - immediately after the filename.docx or whatever, you add a 'comma' then a space and finally add the text or words you want to use in the View as the text to ‘Click On’ to launch the document.
Check that this VAR works directly by manually creating a link to a known Published document etc but strip off the ', Link Here' stuff before you test it.
Then in the WF you need an Update File action which sets the URL field to be the string,
I'd also add some 'Log to History's in the WF which record the value of the VAR you are creating and string etc. You might also need to check things like CheckIn/Out and the impact on the Versioning itself when you run the WF!!
Also beware of Looping as that can cause a problem with 'upon change' WF's and maybe the use of a hidden flag to stop things would be useful as well.
I hope the above helps. If you have any further questions perhaps a personal message or chat might be best? Alan C.
Even more guidance
Sean - I've done a bit more messing since I last emailed and there are some gotchas which I forgot about as I recreated the approach.
Firstly Check In / Out. If you have a WF that runs and needs to check out a document, because the server side of things takes a little time to catch up, you'll need to do a pause for perhaps a minute after you check things out. You can be lulled into thinking that you can use the 'wait for this field to = xxxx, however that's no use if you are controlling the document and it's checked out to you. Also if you try to add after the checkout a 'wait until the CheckedOutTo field has a value', then that never seems to work for me either. The bonkers part is if you have the CheckedOut To displayed in a View, once the WF starts it displays the name but the WF sits in a pausing mode and never progresses. Therefore a pause for 1 min does it for me.
Secondly, triggering the WF to run correctly. Unless you have a triggering mechanism (we use the HarePoint Wprkflow Scheduler as it is FOC), you'll need to have this WF set up as an 'Upon Change' WF. I'd put a 'Wait For XX to equal XX' at the start of it so that it runs once per cycle, and have that either looking for your Document Status or use a Wait for 'Approval Status' to be = '0;#Approved', thus it will initiate properly when the SP internal version has become 1.0/2.0/3.0/4.0 etc.
Thirdly, if you use an 'upon change' WF, as soon as it has run against the 'Approved & Published' document, it will try to run again, however this second time, it will hit the Wait For option of the Approval status as the status will previously have changed from 0 (Approved) to 3 (Draft).
With the above said, create the new URL field in the Library and add that to the Views as needed. In order to stop the field from displaying in the form, you will need to change which fields display on the Properties for the document. You will need to have selected Yes under the 'Allow Management of Content Types' under Advanced Settings for the library, and then you can set the field to be Hidden when you access the Content Type Information description for the document.
So for the WF itself you need:-
- A 'Wait for....' command as above
- A 'CheckOut command for the document.
- A 'Pause for 1/2 minutes'
- A line which sets a new Variable to be the URL string
- A line which records the Variable to the WF history Log
- A line that updates the Current Item's new URL field in the library
- A Checks In action for the document with a comment.
OK, so now for some detail.
- Can be achieved as suggested by using the 'Approval Status' option.
- Under the List Actions group select the 'Check Out' item action, make certain that the Current item is selected.
- As suggested put a 1 or 2 min wait to allow the CheckOut elements to sort themselves out.
- Add a Set Workflow Variable. Click on where it says 'workflow variable' and use a sensible VAR name. Make certain you choose the type as String as this allows a combination string to be created.

Once you've created the VAR title, you should click on the 'value' and then on the elipses button (it is the three dots in a row)
and in there type in the following string:-
http://yourservername/subsite/_vti_history/CurrentItem: UI Version/Lists/LibraryName/Current Item: Name, WORDS

Note - if the WF is going to run immediately after a version has become Published & Approved and has a suffice of zero, you can use the document's 'UI Version' field which is automatically a multiple of 512 here. As I mentioned previously the ','(comma) and the following space followed by your 'WORDS' are used to display a clickable link once you add the column to the View.
- As suggested I'd then use a 'Log (Variable as a String)' to the WF history at this point in order to check when it runs that you are getting it set correct.
- Now you need to add the Variable to the new URL field you've added to the library. As I said this should be a URL type field, and probably is one that you would want to have hidden from the form itself, just having it displayed in a View. Use the 'Update List Item' action, and then set the field to be the VAR.

- Finally add a Check In action then Save and Publish the WF.
You might need to tweak it a bit but in essence this should basically run once every Publish cycle, and if you make it happen as soon as the new major version has been Approved, then it should be good. By using an 'Upon Change' WF, it will then try and run a second time but of course should pause. And because there is an instance of the WF already running (albeit in a paused state), even though you change the document a number of times, you can only have one WF of a type running at a time, and there it is just going to wait until the time is correct and then finish.
I hope the above works for you. Regards