After FPC 3.0 final is released, would we have a bigger probability of a new version of Lazarus 1.4.6/1.4.8 + FPC 3.0 or Lazarus 1.6.0/2.0.0 + FPC 3.0?
since its so easy then how about back porting a couple of bug fixes or components to 1.4.4 add fpc 3 and name it 1.4.6 before stabilizing the utf8 port and lazarus 2.0?After FPC 3.0 final is released, would we have a bigger probability of a new version of Lazarus 1.4.6/1.4.8 + FPC 3.0 or Lazarus 1.6.0/2.0.0 + FPC 3.0?
Lazarus 1.4.6/1.4.8 no.
There are many Unicode related issues involved. We try to solve them with the new UTF-8 system as much as possible, but it still breaks old code in some situations.
But hey, it should not be a problem for you because you can install FPC 3.0 (or the RC versions) and compile Lazarus using it.
since its so easy then how about back porting a couple of bug fixes or components to 1.4.4 add fpc 3 and name it 1.4.6 before stabilizing the utf8 port and lazarus 2.0?
Lazarus 1.4.6/1.4.8 no.
There are many Unicode related issues involved. We try to solve them with the new UTF-8 system as much as possible, but it still breaks old code in some situations.
since its so easy then how about back porting a couple of bug fixes or components to 1.4.4 add fpc 3 and name it 1.4.6 before stabilizing the utf8 port and lazarus 2.0?
Yes, backporting Unicode related fixes should be OK.
Releasing a Lazarus dot maintenance version with the new FPC 3.0 would however break too many things.
So, we would better keep on trunk (FPC 3.1 and Lazarus 1.5) for new projects until FPC 3.0 and Lazarus 1.6/2.0 are released?
Erm I was just being greedy with the back port comment I did not expect anything to come out of it. What it would break to take 1.4.4 as is snap it the brand new fpc 3.0 release and make an 1.4.6 release with out enabling the "unicode" mode, just the way it is now. If it is simple for us to replace fpc 2.6.4 with 3.0 then creating a new version should be easy too, that would allow all component developers to test for a specific version making their life a bit easier (or not) from supporting every vanilla custom build out there.since its so easy then how about back porting a couple of bug fixes or components to 1.4.4 add fpc 3 and name it 1.4.6 before stabilizing the utf8 port and lazarus 2.0?
Yes, backporting Unicode related fixes should be OK.
Releasing a Lazarus dot maintenance version with the new FPC 3.0 would however break too many things.
Proposed fixes to be merged can be added under "Submitted by others" here :
http://wiki.freepascal.org/Lazarus_1.4_fixes_branch (http://wiki.freepascal.org/Lazarus_1.4_fixes_branch)
If it is simple for us to replace fpc 2.6.4 with 3.0 then creating a new version should be easy too, ...
Ok you do see the problem here right?If it is simple for us to replace fpc 2.6.4 with 3.0 then creating a new version should be easy too, ...
Sure it would be easy to create such version but it would have nasty bugs.
FPC 3.0 has a new codepage aware string type. It does not work well with LCL directly. That's why FPC team has kindly provided a system to switch the default encoding to UTF-8 and it works better than we expected in most situations.
Some code however depends on Windows system encoding so much that the new system cannot be used. I have made a new wiki page to list problems and their solutions in such case:
http://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode (http://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode)
In fact I understood that we need to support system codepage with FPC 3.0+ mostly because of feedback from you and some other people. I am a little surprised now that you don't seem to understand the issue at all.There multiple issues here to understand lets just assume for now that I do not understand any of the issues, what I have to do see those problems in my IDE and where can I get the test cases (not code necessarily although most welcomed). I took a look on the meta group you mentioned and most of those bugs seem minor. testing time again I guess oh well.
Anyway, we need help to find solutions and update the new wiki page. Also your help would be appreciated.
So, we would better keep on trunk (FPC 3.1 and Lazarus 1.5) for new projects until FPC 3.0 and Lazarus 1.6/2.0 are released?
I would recommend FPC 3.0 or this RC2 version together with Lazarus trunk if you are interested in its new Unicode support.
If you are interested in latest development in FPC then of course you should use its trunk version, too.
Was FPC 3.0.0 tagged as final on 2015-11-12?
Was FPC 3.0.0 tagged as final on 2015-11-12?
3.0.0 is tagged, and release should be near, very near.
DateUtils LocalTimeToUniversal and UniversalTimeToLocal3.0 final was release on November 25th, 2015, why are you still posting abut RC2 issues? :-\
FPC issue fixed in r31356 (FPC trunk).
Still problem in RC2, Hope you can merge it into 3.0 branch.
While I can see a lot of reasons for limiting the number of variable conditions for working on trunk, this seems to be persistent beyond trunk.
Fedora 26 is currently distributing 3.0.2 that was announced as a "point release", whatever that term signifies.