Re: [Lazarus] IDE still unable to handle path containing spaces?

2009-08-31 Thread Mattias Gaertner
On Sun, 30 Aug 2009 18:47:59 +0700 Bee Jay bee.ogra...@gmail.com wrote: Hi all, While FPC had support for unit path (-Fu) containing spaces, Lazarus IDE still rejects them. If I forced them, the IDE couldn't handle them, as if they don't exist. Is it correct? Or did I miss something?

Re: [Lazarus] Release preparations

2009-08-31 Thread Graeme Geldenhuys
Martin wrote: - with xx being even (24, 26, 28) a released version. the code in this version does not change, a download of 0.9.26 today is the same as 6 month ago Regarding your last statement, that is in theory only! A 0.9.26 download today is not guaranteed to be the same after 6 months.

Re: [Lazarus] Release preparations

2009-08-31 Thread Vincent Snijders
Graeme Geldenhuys schreef: Martin wrote: And there is a Tag for each release. Except not yet for 0.9.28. So ones 0.9.28 is mature I expect it will have a tag. Only thing I do not know is, if those tags ever get moved, which I think they shouldn't? (Exception: If a day or 2 after release, for

Re: [Lazarus] Release preparations

2009-08-31 Thread Vincent Snijders
Graeme Geldenhuys schreef: Vincent Snijders wrote: Graeme, thanks for this nice piece of ASCII-art. Can you add it to http://wiki.lazarus.freepascal.org/Version_Numbering , please? Done! Thanks, I tried to expand it a bit and hope it makes it even more clear. Vincent --

Re: [Lazarus] Release preparations

2009-08-31 Thread Graeme Geldenhuys
Vincent Snijders wrote: Thanks, I tried to expand it a bit and hope it makes it even more clear. Pleasure. You read my mind. Afterwards I thought I better add the branches\ prefix and 0.9.25 in there as well. I clicked Edit and saw them already added. :-) It looks better and more complete

[Lazarus] Git mirror now tracks fixes_0.9.28 branch

2009-08-31 Thread Graeme Geldenhuys
Hi, Just to let anybody interested know that fixes_0.9.28 is now being tracked in the Git mirror as well. I'm using Git's cherry-pick command against trunk to keep the new branch in sync - which also as the benefit that the 'git pull' has even less to download. There is no need to re-clone the