Community
Participate
Working Groups
In p2 install when we show version numbers, you usually see something like: 3.4.0.v20081009-1800-SomeRandomAssortmentOfLettersAndNumbers For most users, all they really want to see is "3.4.0" with maybe the rest available in the Details area. As I understand it, what we're showing is the version information in repo, that the shorter (human readable) version number isn't available. This suggests two choices: 1) Add the extra human readable label to the xml, try to get teams to use it. 2) Rely on the fact that projects always use major.minor.maintenance numbering and do a string cut beyond that pattern (ie. just chop off the third dot and everything after). If it doesn't fit that pattern, don't cut it. The full string will always be available in details so there's no real loss of information.
I agree they are harsh, however, I find the qualifier the most interesting part. I don't know what 4.3.1 is, but 20090205 means something to me (hey this is the feb 5th 2009 version, cool, it's new). +1 for suppressing SomeRandomAssortmentOfLettersAndNumbers from the UI.
(In reply to comment #1) > I agree they are harsh, however, I find the qualifier the most interesting > part. I don't know what 4.3.1 is, but 20090205 means something to me (hey this > is the feb 5th 2009 version, cool, it's new). Sigh, as always in Eclipse, it all depends on who "you" are. For many they only update at the release level so the timestamps are meaningless, but if you're riding the milestones then they are. But in this later, case, by default we hide things that are already installed. So until say a new milestone came out then you wouldn't see it listed. Would being able to get the timestamp from the details not be enough then? As a last resort there's the ol' [X] Show full version information The problem is that the additional timestamp info creates visual noise which makes it harder to parse for those who only care about release levels. I should add that some updates are only of this version.date form without the crazy stuff at the end and are presently I find hard to parse. > +1 for suppressing SomeRandomAssortmentOfLettersAndNumbers from the UI. Actually should have written it as OMGWhatAreAllTheseLettersAndNumbers.
I think you really need a human readable branding version. You can't in general say that the actual version numbers (major.minor.service) correspond to releases in any way that is meaningful to an end user. Particularly if people are actually following the versioning guidelines.
(In reply to comment #3) > I think you really need a human readable branding version. > > You can't in general say that the actual version numbers (major.minor.service) > correspond to releases in any way that is meaningful to an end user. > Particularly if people are actually following the versioning guidelines. I agree that's the right solution but I seem to recall that there was some issue with it, perhaps it had to do with legacy install config representation.
Just to clarify what you are seeing here: these really are just the plain old feature version numbers, not some special p2 version number. We have always had the same harsh versions under Help > About > Feature details, for example. If we start truncating or otherwise altering feature version numbers at the glass, p2 and others will have to do it consistently in several places.
I'm not sure I'd characterize this as an enhancement since I believe the current presentation is a usability issue.
this is the "marketing version number" discussion again. I'm all for having explicit marketting version numbers. Lets call them what they are. Just truncating the real version number feels like a recipe for confusion.
(In reply to comment #7) > this is the "marketing version number" discussion again. I'm all for having > explicit marketting version numbers. Lets call them what they are. Just > truncating the real version number feels like a recipe for confusion. > Agree. (Also, with the "OmniVersion" and support for different version numbering mechanisms, truncation rules aren't straightforward)
(In reply to comment #7) > this is the "marketing version number" discussion again. I guess, maybe it's just the term "marketing" that's throwing me off. I'm just looking for something a human can read, since presumably the reason we're showing these things in the UI is for a human to make a decision based on them. This requires someone to be able to parse and differentiate. But everything right of the time has all the appeal of a generated cryptographic key. It just happens that in practice we never have two things that are only differentiated by that, because otherwise choosing the right one would be massively error prone. Pop quiz: which of these is the right one for Data Tools Platform Enablement? 1.6.1.v200809191145-7D8H7C9FSw0BZabCz-MXEZLR8Rnc 1.6.1.v200809191145-7D8H7C9FSw0BZabCz-MXEZLR8Rnc 1.6.1.v200809091145-7D8H7C9FSwOBZabCz-MXEZLR8Rnc (and yes I actually typed all that in because I couldn't copy it from the UI). So not only do they not add UI value, but their existence makes it harder to parse the stuff you do need to read, and are thus a net negative. > Just truncating the real version number feels like a recipe for confusion. Actually that's also the current situation :) Just to confirm: is there then no technical or compatibility roadblock to introducing human readable version numbers? It was the only reason I suggested the hack truncation.
> (In reply to comment #7) > > this is the "marketing version number" discussion again. > > I guess, maybe it's just the term "marketing" that's throwing me off. > The "marketing version" addresses human readability and also the the old problem of versions that mean something to developers (various version rules involving API breakage, etc.) vs. versions that line up with an overall marketed product version. > Just to confirm: is there then no technical or compatibility roadblock to > introducing human readable version numbers? It was the only reason I suggested > the hack truncation. AFAIK, the issue is one of the metadata and tooling, and perhaps making some technical assumptions. We would need to define a property that contains this version, ensure that PDE and publisher tooling allowed the user to define it. For old update sites without p2 metadata, there would still need to be some hack, and maybe truncation is the answer. Also clearly define how the property is used (presumably not for install resolution or for deciding what the latest version of something is)...that is where it can get tricky. In your example truncation is tricky because part of the version qualifier is useful (the date part) and part of it is not, so I'm not sure how the UI would truncate. Those qualifier numbers at the end are generated by PDE (I'm *pretty* sure) so that the versions of things exported for each build actually change. > (and yes I actually typed all that in because I couldn't copy it from the UI). sorry. (bug 227220, coming soon)
For a feature, the timestamp isn't particularly interesting either. This just means the last time the *feature* itself was changed in CVS (usually the feature.xml file). It doesn't tell you anything about when any of the plug-ins in that feature changed. If a feature.xml remains stable, the timestamp may remain unchanged for long periods of time even if the plugins inside the feature have changed recently. The "random numbers and letters" tell you that the plugins in that feature have changed, although not in a human-understandable way (unless you happen to be fluent in base-64).
Re comment #9: regarding the pop quiz, I suppose those are versions that were presented in the available software dialog? If we truncated the qualifier and there were just three different entries with the exact same version (1.6.1), would you be any better off?
The difficulty with truncating is that then when an update is available the user can not distinguish what it is unless you start showing up the actual version number. For example I have eclipse 3.5.0 installed and next week I will be told that I should update to 3.5.0!!!
(In reply to comment #12) > Re comment #9: regarding the pop quiz, I suppose those are versions that were > presented in the available software dialog? No actually only one of them was right, the other two were decoys, the game was to figure out which was the right one. > If we truncated the qualifier and > there were just three different entries with the exact same version (1.6.1), > would you be any better off? My claim is that no two versions *ever* differ by only the amount I showed, and if they did, you'd never be able to tell them apart anyway. They serve no purpose to a human being, AFAIK. (In reply to comment #13) I understand the problem with trying to automagically hide the details of the version information, but I'm still going to argue that most of the time it only hurts. Consider update in the context of commercial applications. The version information as displayed is brutal. I don't think I've ever seen an update system that exposed me to information of that density. Consider also that most consumers will only take major versions but nothing less. Heck, they're even reluctant to do that, and maintenance releases only if it has a critical fix. They need something simple they can 'grok' to determine if they should hit the update button. Major.minor.maintenance is it. It's only if you're riding the milestone wave that you care about anything at a smaller granularity. I think it's ok to require more effort to support this latter set of people (i.e. us), say through the use of a "Show More Version Details" checkbox or something else, than to impede the task for commercial end users. And if you really had two versions that only differed by something that you would've truncated then ... don't truncate it in that case! :)
(In reply to comment #13) > For example I have eclipse 3.5.0 installed and next week I will > be told that I should update to 3.5.0!!! > I think this highlights one of the problems. Why publish two 3.5.0 releases that only differ in qualifier? If some bug was fixed, then why wasn't the version bumped to 3.5.1? Isn't that what the bugfix/micro version is for? I think that the default behavior should be to disregard updates that are reflected by changes in the version qualifier alone. If you are one of the rare people that care about such changes ("i.e. us" to quote Kevin) then you should set a special preference to indicate that you want qualifiers to be considered (and indeed made visible).
(In reply to comment #15) > I think that the default behavior should be to disregard updates that are > reflected by changes in the version qualifier alone. If you are one of the rare > people that care about such changes ("i.e. us" to quote Kevin) then you should > set a special preference to indicate that you want qualifiers to be considered > (and indeed made visible). > But that opens up a different kind of worms - if you want to discriminate "snapshots" - it means that selection of IUs can not be made by only looking at version ranges. Some other property must indicate if it is a "release" or a "snapshot" and be used to filter out unwanted items.
I understand the end user goal of providing a more readable version. This is to me the marketing number. This version number would allow for example to show 3.5.0 M5, or even better "Platform Galileo M5", ... to the end user instead of the cryptic version number. However behind the scene there is still a real version number required that can capture all the things that the versions capture today like dependency verification, search for update, etc. So, my proposal is to leave our cryptic version numbers as they are because they are still useful for a variety of things, and to allow for each IU to potentially have a "user friendly version number". From there the UI could have a preference to show complete version numbers or user friendly version numbers and would show what is requested.
Right, what I suggested originally was that we would continue to show the extended version number in the Details area. Baring that we could provide a [X] Show mindboggling version information option although my believe is that that extended information is mostly of use to a small community of people (like, those who built the tool <g>) and therefore I'd prefer to avoid an option (but details area is fair).
(In reply to comment #17) > ...and to allow for each IU to potentially have a "user friendly version > number". If the publisher must provide a "user friendly version" anyway in order to for the version to make sense, then why not provide that as the real version and skip the auto-generation? I would argue that most of us use the qualifier incorrectly and have become very lazy regarding the micro version number. Take a look at an eclipse distribution. Almost all bundles that Eclipse deliver have a micro number of '0' or '100' (some exceptions in EMF and p2). Why is that? Surely there are a whole bunch of bug-fixes. But instead of bumping the micro number (a manual effort), we rely on the auto-generated qualifier. That in turn is the cause of all ugly and unreadable versions. Especially when it comes to the features. IMHO, introducing the ability to add yet another version will not rectify the problem. It will add to the overall confusion and make things worse. A better approach would be to provide guide-lines about how to use the micro-number in combination with more readable qualifiers (build numbers, revision number where applicable (alas, not in CVS), or timestamps). The commonly used base64 encoded qualifier used for features is utterly horrible and since these are the versions that the user is exposed to, such qualifiers should be removed altogether.
Versioning guidelines have been provided for years at http://wiki.eclipse.org/Version_Numbering but they have been missing the appropriate tooling up until last year and the API tools. Now as for changing the way we version things, this is not a discussion to have here and I'd argue that it is too late anyway when you see the resistance that some ppl put to having must-haves for galileo and following a small set of rules. On top of that I don't see where the problem is with the current versioning scheme. Another thing to consider is of course that all bundles are made of OSGi numbers. Side question, Thomas, how would an OmniVersion be presented to the user in the UI?
(In reply to comment #20) > Side question, Thomas, how would an OmniVersion be presented to the user in the > UI? > We envision a solution were the tooling will maintain a map keyed by format strings. The value of each entry in the map is then a list of known names for the format. In most cases there will only be one name in that list. The idea is to allow a format author to publish a name for his format. If other format authors come up with the same format but use a different name for it and both publications are loaded into the same environment, then the user would see two alternative aliases for the format. The presentation of the version would typically be the original version string and the format name, i.e. "1.2-CF1 - Mozilla". The raw version and the format string should IMO not be displayed unless explicitly requested. Exactly how the format names are published is yet to be decided. Personally, I would like to see some tagging support in a P2 MetadataRepository by which we could tag both IU's and version formats (and perhaps other things as well). A tag in this case would have a type and also be subject to NLS.
OmniVersion has the ability to handle an "original version string" when using the raw and format string encodings - i.e. it is possible to declare something like "raw:3.5.1.'2009-JDKDFJUHghbf634'/:Galileo 3.5.1 special". Which means an osgi compatible version with an original version string of unknown/untranslatable format. However... the intention of the "original string" was not to support a marketing name, but to provide both the source and format so a user could edit a version and create a new raw, but maybe worth considering exploring for other cases of "human readable version". When the format is unknown there are issues regarding how comparisons can be made against other versions... but I am sure it can be made to work if there is interest in using OmniVersion for human readable names. With OmniVersion it is possible to get the various parts of the version separatly, so I UI can do what Thomas just described - lookup the format name/alias, etc. I do think that a separate "version name" or "version description" is a better solution than overloading OmniVersion with yet another aspect of the version.
> The commonly used base64 encoded > qualifier used for features is utterly horrible and since these are the > versions that the user is exposed to, such qualifiers should be removed > altogether. These ugly qualifiers aren't just there for the fun of it. Without these qualifiers everything breaks - the build breaks, and p2 breaks. It causes the new feature to be ignored and the old one kept, typically causing install errors due to incompatible version requirements. The basic problem is that features include precise versions of bundles that are inserted into the feature at build time. When any bundle in the feature changes, the feature version must also change because the feature IU has different required capabilities. I think the problem here is not the existence of these qualifiers, but the overt presentation of these qualifiers to the end user. I tend to agree that the vast majority of end users consume only releases, and since one of major.minor.service numbers must always change in each release that has different contents for an IU, the three part version number is sufficient to uniquely identify a release from the *typical user's perspective*. After thinking about it more, I think it would be interesting to explore showing just major.minor.service in the table-trees of the Available Software and Installed Software dialogs, and putting the fully qualified version number in the details pane below.
(In reply to comment #23) > When any bundle in the feature changes, the feature version must > also change because the feature IU has different required capabilities. > I know the reason why it's there, but given that this is the version of an installable (visible) feature, I think the generation of the version could be vastly improved. I know it's far to late in the process right now but envision a build system that keeps track of the long and horrible base64 encoded strings for each feature in a map. The map translates the string into an integer used as a micro number. When the base64 string changes (increases in magnitude), the micro number is bumped. That would enable "safe" feature versions without qualifiers. The only problem to overcome would be to define where the map would be kept.
I was thinking about this problem today and was wondering if we could somehow make the UI smart about what it shows... make it base its decision on its current context and what it currently has installed. It would be cool if the UI showed the minimum that you would need to show the user to indicate there was a change. (e.g. it would do a comparison with what is already in the profile) For instance, if you have the SDK 3.4.1.100 installed. - on a site with 3.4.2.100 you would show "3.4.2" - on a site with 3.4.1.101 you would show "3.4.1.101" - on a site with 3.5.0.0 you would show "3.5" Of course as mentioned above you would need some mechanism (details pane? preference? checkbox?) to always show the full version including the qualifier. The above system also might look at little weird as you would have some short and some long versions when you visit a site with lots of different things on it, some already installed and some new.
Created attachment 128953 [details] What version would you choose? While much of this discussion is around improving the presentation of the version numbers, I have actually hit a pretty big usability problem with the current implementation (especially after doing week 2 week upgrades). I was trying to construct a product based on features, and I have multiple versions of the RCP feature. They only differ in the non-human readable qualifier. I was forced to "guess" when building my product, and here's the catch, if you guess wrong, exporting the product fails! I would propose that this bug (or at least the parts that cause users to fail) be upgraded from "enhancement". If we really are requiring users to guess, we should at least have a checkbox that filters all but the latest version. If a user wants something other than the latest, they can uncheck the box, manually convert the base 16 part to something they can understand, and choose the desired version. I have attached a screenshot to show you the selection dialog I am being faced with. (I only did 1 week to week upgrade.. imagine if somebody followed the advice and did this every week for a year).
> > I have attached a screenshot to show you the selection dialog I am being faced > with. (I only did 1 week to week upgrade.. imagine if somebody followed the > advice and did this every week for a year). > I think you want to open a bug against PDE UI (that is not a p2 dialog in the screenshot). This is a build-time dilemma (although I sympathize!) In p2, only the latest version is shown when presenting updates unless the user has unchecked [ ] Show latest version only when browsing updates in the preference dialog. Likewise, they have to uncheck a similar checkbox on the install new software page.
*** Bug 285685 has been marked as a duplicate of this bug. ***
Marking M4 since we are looking at other things that would make things cleaner for the simple cases (ie, only one install root to update, user can only update but not install, etc.).
Removing a specific milestone since this is still in the inbox.
Don't see this being done unless somebody steps up to it for this released. The changes imply: - defining a concept of marketing version number - changing the UI code to use it - make sure it can be passed in the p2.inf or other editors.
This issue died.
