For me sound good Harbour 1.5 because it is a release intermediate from 1.0 to 2.0I have not evaluated the effect of release number in xharbour but we have a very special content MultiThrea,Multiwindows,Hbmk2,hbqt,rddsql and the grooving of library like gtwvg I think that a lot of user migrating from xharbour when harbour give gtwvw compatibility from gtwvg ...seem that about 8% of [x]harbour user use gtwvw (source http://cch4clipper.blogspot.com/) Content of harbour is more important that "versioning numbering" but
for having 2.0 numeration we need something like netgt or netrdd or gtweb ie,firefox 2009/5/29 Viktor Szakáts <harbour...@syenar.hu> > >> 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 > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
