>> Well, the main reason is that users cannot really grasp the difference >> between Harbour and xhb. Many of them think they are the same thing. >> Now, if we don't adapt / react to that, and always keep low profile, the >> notion will be that we're not doing anything, as our version number >> suggest that we're just an older version of the same thing. Which isn't >> further from the truth. Stupid as it is, it still seem to hold true. > > I think we were talking about version numbering before 1.0.0 RC. My opinion > is not changed from this time. Larger version number does no associates for > me to a better product, but conservative version umbering do associates.
I agree with you, but generally users (even developers, sometimes even me) aren't such "wise" in this regard :( IMO we should avoid being driven by insane version increases, but we certainly have more freedom in forming it than adding +1. > Talking about xhb/Harbour.... You can do next version 1.6 or 1.20. You'll > get next xHarbour to be 1.7 or 1.50. It's just a question: who knows a > larger number?... I do not think it is worth to play these games. Valid question. I don't know, and it may well happen, so most probably we should somehow try to emphasis the differences / advantages by some other means. >> BTW, just a little statistics: 1.0.1 was r9429, currently we're at r11179, >> 1750 commits after (18% increase), ChangeLog size was 3.2MB, now >> it is 4.5MB, 1.3MB or 40% increase. This is huge, not a minor release. >> If you check the whatsnew doc, there are tons of stuff in it, even now, >> not even half finished. > > I understand your idea. But I think it's better to follow some accepted > numbering scheme. It can be any: > 1.0906 // for June 2009 > 1.11179 // for revision number > 1.45 // ChangeLog size in 100kB > 1.0 -> 1.1 -> 1.2 -> etc.... > > I just thought we use the last one. Yes, all these are options. I don't personally like these "speaking numbers" though. They are usually redundant and for me they tell even less than the classic solution, where you can usually conclude from the version number *increase* the expected amount of changes in a product. (until the marketing department took over the development dept. that is) So, if the developers (who know best) decided this is a +0.5 increase that tells me they've pushed it much harder, than - say - for a +0.1 increase. And an +1 increase tells that something even bigger was done. Neither of these break the rule to signal compatibility levels, as *any* change in minor (in "major.minor.release") revision means no guarantee for compatibility anyway. So maybe we should rather concentrate on that, without being carried away by xhb version numbering, and IMO if we do this, we can still increase our version number by > 0.1 (if we agree to do so) to reflect the amount of changes, which was very high since prev release. >> Odd-even notation: I've been also thinking about it, maybe we can use >> it to replace 'dev' postfix. Since our 'dev' is quite stable and lasts for >> quite long, maybe it merits it's own version number for easier reference. > > I agree with this idea of version numbering selection. I this case our next > release should be 1.2. By the way, what (odd or even) version numbers other > products use for stable releases? It would be better to follow a general > rule if it exists. Even numbers meant stable versions in Linux kernels, odd ones the development versions. We're in sync with that currently. Brgds, Viktor _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
