[fpc-pascal] Some features for FPC 3.0?

[Lukasz Sokol]

Hi Marco, 

On 17/02/15 21:09, Marco van de Voort wrote:
> In our previous episode, silvioprog said:
>>
>> My suggestion is just: to make easier to test, for any programmer. E.g:
>>
>> - fpc-3.0.0-beta1/beta2 +/-jan/feb
>> - fpc-3.0.0-RC1/RC2 +/-may/jun
>> - fpc-3.0.0-RC3/fpc-3.0.0-stable +/-dec.
>>
>> Yes, it is hard to do, but IMHO it is necessary.
> 
> I don't think this needs to be done formally. Any users can package
> snapshots cq pseudo releases and mark them as test, and release them for
> feedback. Then process the feedback, triage it, and communicate that back
> upstream.

Which sometimes takes so long, that the downstream tester bypasses the distro
maintainers and submits patches directly upstream...
... only to find out that his patches are not going to be present in /this/
incarnation of the distro release and he'll be lucky  if they actually hit the next one.

> 
> That's how the really big projects (like distros) work too. Similarly with
> the various branches of the Linux kernel, where there are often third party
> builders that track a certain target.

Linux approach changed around 2.6.12 somewhere (or later) with/after the upcome of git...
now they have 6-9 rc releases, merging new features AND bugfixes, one per week or 1.5 average, 
then branch the head off and the stable branch is strongly advised to be sent bugfixes /only/.

This alone has reduced the gap between what distros used to package, even if it's wheezy-backports
I have to add to my repo list to get a 3.16 kernel... while the head is 3.19 looming on 4.0;
but that is only 4 major* releases behind - when in early days they went on forever maintaining up to 2.4.89,
because there was demand... and still some people/distros stayed on 2.4.[pick an earlier number] 
and grumbled... about the threshold of switching to 2.6.x ... or even to 2.4.x+1 sometimes.

(Truth be said, I /do/ see resemblance of LK to FPC approach, only FPC has a slower 
pace and uses different numbering scheme, (which can be (mildly) confusing when 
one switches contexts often;) also you call it feature-freeze, they call it stable branch... 
but it's the same idea in its essence)

(* yeah, yeah, they call it 'minor', so what. any release I don't have yet, is a major one to me)

> So the question should be, when do you think you can release your first
> pseudo stable snapshot? Throwing it all back to core is useless, since that
> increasing tasks will only slow development more.

I for one think, that just encouraging /anybody/ to release pseudo-stable snapshots,
is not going to help, rather end up with some of them being forks, fragmenting the ecosystem...
(remember the times of linux 2.4.x-ac or -mm versions?)

You might end up with some people that are less patient instantiating their own git repos, 
and adopting faster pace, and the main repos becoming outdated... because their downstream 
patches won't apply to upstream without considerable amount of work.

I'm actually with Silvio on this : do keep calm and carry on with your numbers scheme, since it suits your needs;
only maybe shorten the time between major stable releases ?

(maybe by altering the criteria, of how much of a change is considered fit for a next major release, 
  /considerably/ down; 
 even if it means, if tracking the features of Delphi compiler is any factor, 
 that for 1 Delphi release, FPC releases 5 or 6 major releases before it catches up)

So that you get the downstream people tracking /behind/ you, not reverse : smaller changes made more often, 
are proven to be more stable, and are less of a burden on testers, and less trouble porting programs 
from one version to next version, as Linux example actually does show. 

Just My 2 zl / 20p ;) worth of synthesis/comparisions from reading LKML and FPC-general list ;)

(and I'm just a user who likes using stable releases ;) 
but Lazarus in my wheezy from main repo is 0.9.30.4 ... how old is that...? )

Lukasz