> 2011/3/3 Robert Norris : > > > > > > Hopefully as you may have already seen my idea of version 1.2: > > > > https://sourceforge.net/apps/mediawiki/viking/index.php?title=Roadmap_1.2 > > Since we released 1.0 (and also 1.1), we certainly have to discuss the > numbering scheme to use. > > There is a lot of way to address this issue. > http://en.wikipedia.org/wiki/Software_versioning > > For 1.0, I tried to import the idea of "stable" release (I then > released 1.0.1 and 1.0.2). I don't know if it was usefull or not, nor > if viking is sort of software that need such effort. The main idea was > to use even releases as stable ones and odd releases for > developpements (like Linux AFAIK). > > I also noticed that the numbering scheme based on using third digit > for bug fixes and second digit for enhancements is not easy: all > releases of viking contain both fixes and enhancements. > > What's your opinion, prefered version numbering scheme?
1.2, 1.3, 1.4 ...... I've given up on caring about *any* software version - I want the 'best' / most featureful - hence it is always the latest. I run Debian unstable, and update every few days/weeks. This sums up my position quite well: http://www.codinghorror.com/blog/2007/02/whats-in-a-version-number-anyway.html Especially for desktop programs with no compatibility concerns ATM, so to my mind there is only 'latest' version which the git head and the latest versions shipped by distributions / Windows SF binary - things that *most* end users will get it by. I think 1.0.X should only get 'critical' bug fixes (i.e. crashing ones). At some point patches can't be applied cleanly from the head into the older version(s) without some extra manual effort. In essence the git head is 1.1.X, where every update is an new ..X. At some point we decide a bunch of features (mostly developed in separate git trees) will get merged. This then becomes the next line in the sand - i.e. 1.2 in the light of simplicity. If any one is bothered they can create git branches from 1.1 and apply patches themselves from the then new 1.2.X head. I guess I'm trying to say I'll maintain only the git head, as that's what interests me. If people want help on any particular version I don't mind - just that I'm not going to update old releases for them (except 1.0). An associated thought: it might help to embed some kind of file versioning number into a .vik file - this could make future variants of the file format potentially easier to auto-convert / be backwards compatible if necessary. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
