From: Mark S. <mar...@ch...> - 2006-07-09 18:08:44
|
Borut, thanks, these ideas are great. Since it looks like I can edit the wiki without any special permisions I should be able to get started on this in the next few days. --Mark On Jul 9, 2006, at 12:13 AM, Borut Razem wrote: > Mark Swayne wrote: >> Thank you all for your hard work. >> >> Is it possible that the library licensing issue will be resolved >> for the >> 2.6.0 release? ... > Yes, there are many things to do: > > - Prepare a "SDCC Library License Transition Plan" on the SDCC > Realease > Wiki, > > <SNIP> > Borut > |
From: Frieder F. <fri...@we...> - 2006-07-11 09:45:46
|
Hello Borut, Mark Swayne schrieb: > Borut, thanks, these ideas are great. yes, thanks!) Could you add a subversion tag for the Release Candidate so the RC would show up at: http://svn.sourceforge.net/viewcvs.cgi/sdcc/tags/ Greetings, Frieder |
From: Borut R. <bor...@si...> - 2006-07-11 18:56:44
|
Frieder Ferlemann wrote: > Could you add a subversion tag for the Release Candidate so > the RC would show up at: > > http://svn.sourceforge.net/viewcvs.cgi/sdcc/tags/ > Done. Tag name is sdcc-260-pre1. Borut |
From: Maarten B. <sou...@ds...> - 2006-07-09 08:45:58
|
Mark, Borut, > My idea is to make an other official build with the changed license in few > months after 2.6.0 release. The version number might be 2.6.5, not to ruin > the version number - release year correlation :-) It's good to create another official build a few months after 2.6.0, but I would not mark it 2.6.5. My choice would be 2.7.0. Let's keep non-zero ending version numbers for the snapshots. In my opinion there is / should be no correlation between version numbers and release years (ok, they both gow upwards and besides, in few months it will be 2007 already). By the time we get to the new release the PIC16 port might pass regression tests too. Maarten |
From: Bernhard H. <sdc...@be...> - 2006-07-10 20:26:51
|
> Yes, I received it, but there was not mentioned much about the release... > I would like to hear something from others too (Raphael, Bernhard, Erik, > Vangelis, Frieder and others: > are you already on vacantions?). Not yet :-) I'll leave tomorrow for two weeks. Here are my two cents: - Releases are important, and sdcc is again overdue. - I see no show-stopper. Just the pic lib build should be silenced. - IMO it's wise to postpone the license problem. You're doing a great job, please go on! Please sync in the relase the versions in the files ".version" and "sdcc.spec". One proposal for the pic lib build: it's cheap to enclose debug code by getenv(): if (getenv ("SDCCPICDEBUG") { puts ("Warning: I just saw a dead horse!"); } The interested developer sets the environment variable SDCCPICDEBUG, and you can output anything you want without annoying anybody else. Bernhard |
From: Raphael N. <rn...@we...> - 2006-07-18 16:52:21
|
> > Yes, I received it, but there was not mentioned much about the release... > > I would like to hear something from others too (Raphael, Bernhard, Erik, > > Vangelis, Frieder and others: > > are you already on vacantions?). Indeed I have been off my box for some days ;-) > Not yet :-) I'll leave tomorrow for two weeks. Here are my two cents: > - Releases are important, and sdcc is again overdue. > - I see no show-stopper. Just the pic lib build should be silenced. [snip] > One proposal for the pic lib build: it's cheap to enclose debug code by > getenv(): > if (getenv ("SDCCPICDEBUG") > { > puts ("Warning: I just saw a dead horse!"); > } > The interested developer sets the environment variable SDCCPICDEBUG, and you > can output anything you want without annoying anybody else. Done for the two annoying warnings, thanks for the hint using getenv()... Should I commit it before the release? Should this "feature" be documented? Raphael |
From: Maarten B. <sou...@ds...> - 2006-07-18 19:22:30
|
Raphael, > > One proposal for the pic lib build: it's cheap to enclose debug code by > > getenv(): > > if (getenv ("SDCCPICDEBUG") > > { > > puts ("Warning: I just saw a dead horse!"); > > } > > The interested developer sets the environment variable SDCCPICDEBUG, and you > > can output anything you want without annoying anybody else. > > Done for the two annoying warnings, thanks for the hint using > getenv()... Should I commit it before the release? Should this "feature" > be documented? As temporarily appointed release manager, I'd say yes commit. The PIC build generates too much noise. Should you document it? Probably inline and on the developer mailing list is enough. Try to build SDCC with 'make -s' and it should only generate errors and warnings, if any. Greetings, Maarten |
From: Raphael N. <rn...@we...> - 2006-07-20 14:19:16
|
Hi, > > > One proposal for the pic lib build: it's cheap to enclose debug code by > > > getenv(): > > > if (getenv ("SDCCPICDEBUG") > > > { > > > puts ("Warning: I just saw a dead horse!"); > > > } > > > The interested developer sets the environment variable SDCCPICDEBUG, and you > > > can output anything you want without annoying anybody else. > > > > Done for the two annoying warnings, thanks for the hint using > > getenv()... Should I commit it before the release? Should this "feature" > > be documented? > > As temporarily appointed release manager, I'd say yes commit. The PIC build generates too much noise. > Should you document it? Probably inline and on the developer mailing list is enough. > Try to build SDCC with 'make -s' and it should only generate errors and warnings, if any. As previously, SILENT must be set to really quieten the PIC library builds, but "make -s SILENT=1" now only emits a single warning (SDCC r4294). I guess this should do. Regards, Raphael Neider |