From: Borut R. <bor...@si...> - 2009-07-21 06:33:55
|
Hi Frieder, in the sdccman.lyx you wrote: "The medium digit in the version number denotes the year of the release"... I think it was never agreed to be so and it is so only by coincidence. I even haven't noticed it until somebody wrote it... OK, it is true that we are keeping this "coincidence" alive for some time, but it is not a rule an it is not said that it won't be changed in the next releases. Maybe we will even change the major version number some day... I propose to reformulate the sentence to something like: "The medium digit in the version denotes the minor version number and the last digit of an official release is zero." Borut |
From: Frieder F. <fri...@we...> - 2009-07-21 07:51:39
|
Hi Borut, Borut Razem schrieb: > in the sdccman.lyx you wrote: > "The medium digit in the version number denotes the year of the release"... > I think it was never agreed to be so and it is so only by coincidence. I > even haven't noticed it until somebody wrote it... OK, it is true that > we are keeping this "coincidence" alive for some time, but it is not a > rule an it is not said that it won't be changed in the next releases. Yes. I was happy that SDCC's version number is one of the few version numbers that directly translate into a meaning. > Maybe we will even change the major version number some day... Good point - we indeed run into an irregularity for the next release. On the wiki it is referred to as 2.10.0 but having two digits for the minor number (or the minor minor number) does not play nice with the define "SDCC" which since #1449908 holds the version number (currently 292) > I propose to reformulate the sentence to something like: > "The medium digit in the version denotes the minor version number and > the last digit of an official release is zero." Maybe add something like: next release will be called thisandthat and the minor minor number is meant to always fit into a single 0..9 digit? Greetings, Frieder |
From: Borut R. <bor...@si...> - 2009-07-21 08:31:59
|
Frieder Ferlemann wrote: >> Maybe we will even change the major version number some day... >> > > Good point - we indeed run into an irregularity for the next release. > On the wiki it is referred to as 2.10.0 but having two digits > for the minor number (or the minor minor number) does not play > nice with the define "SDCC" which since #1449908 holds the > version number (currently 292) > I don't think that next release will be so special that we'll need to change the major version number. I even think that the next release will be more or less a bug-fix and maintenance release without new functionalities (not counting support for new PIC and other models). So I wouldn't change the major version number. The SDCC define is really a problem. We could change it in the way that 2 digits are reserved for minor and sub-minor (or revision or patch...) numbers: SNPRINTF(buf, sizeof(buf), "-DSDCC=%d%02d%02d", SDCC_VERSION_HI, SDCC_VERSION_LO, SDCC_VERSION_P); (I hope that in next 90 years we will find an excuse to change the major version number ;-) so the value for SDCC 2.10.0 will be 21000. What do you and other developers think about it? Borut |
From: Frieder F. <fri...@we...> - 2009-07-21 16:58:27
|
Hi Borut, Borut Razem schrieb: > I don't think that next release will be so special that we'll need to > change the major version number. I even think that the next release will > be more or less a bug-fix and maintenance release without new > functionalities (not counting support for new PIC and other models). So > I wouldn't change the major version number. The SDCC define is really a > problem. We could change it in the way that 2 digits are reserved for > minor and sub-minor (or revision or patch...) numbers: > > SNPRINTF(buf, sizeof(buf), "-DSDCC=%d%02d%02d", SDCC_VERSION_HI, > SDCC_VERSION_LO, SDCC_VERSION_P); > > (I hope that in next 90 years we will find an excuse to change the major > version number ;-) > > so the value for SDCC 2.10.0 will be 21000. > > What do you and other developers think about it? Frankly, I would not like this. What is so special about the next release that we should change the versioning scheme?^) a) It breaks existing code: #ifdef SDCC # if (SDCC <270) # warning please use SDCC 2.7.0 and up # else # define COMPILER_VERSION {'0' + SDCC / 100, \ '.', \ '0' + SDCC % 100 / 10, \ '.', \ '0' + SDCC % 10, \ 0x00 } # endif #else # define COMPILER_VERSION "?.?.?" #endif b) it needs two bytes more when stored or transmitted as string c) if listed in a directory: sdcc-2.10.00-i386-unknown-linux2.5.tar.bz2 sdcc-2.11.00-i386-unknown-linux2.5.tar.bz2 sdcc-2.12.00-i386-unknown-linux2.5.tar.bz2 sdcc-2.3.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.4.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.5.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.6.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.7.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.8.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2 versus: sdcc-2.3.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.4.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.5.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.6.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.7.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.8.0-i386-unknown-linux2.5.tar.bz2 sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2 sdcc-3.0.0-i386-unknown-linux2.5.tar.bz2 sdcc-3.1.0-i386-unknown-linux2.5.tar.bz2 sdcc-3.2.0-i386-unknown-linux2.5.tar.bz2 there will be mistakes if you tell someone to pick the latest version. Greetings, Frieder |
From: Maarten B. <sou...@ds...> - 2009-07-21 20:34:47
|
Hi, I would not mind to call the next version 3.0.0 with a define SDCC=300. After all, what's in a number? Back when I introduced the SDCC define I hoped that at least the PIC16 would become stable before we would reach the end of 2.9.x. And that would qualify as a good enough reason to increase the major. But I'm afraid it doesn't look like it's going to happen. Maarten |
From: Borut R. <bor...@si...> - 2009-10-04 15:10:43
|
The majority of developers who responded to my mail voted for 3.0.0 (Maarten and Frieder against me ;-) . So the next sdcc release version number will be 3.0.0. I'll rename the wiki pages. Frieder, can you please correct the chapter "7.7 Release policy" in sdccman.lyx? Borut Maarten Brock wrote: > Hi, > > I would not mind to call the next version 3.0.0 with a define SDCC=300. > After all, what's in a number? > > Back when I introduced the SDCC define I hoped that at least the PIC16 > would become stable before we would reach the end of 2.9.x. And that would > qualify as a good enough reason to increase the major. But I'm afraid it > doesn't look like it's going to happen. > > Maarten > > ------------------------------------------------------------------------------ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > |